使用SetProcessWorkingSetSize的优点和缺点

我的应用程序中有内存pipe理问题。 应用程序内存在运行时迅速增长。 我在断开模式下使用数据集。 为了解决这个问题,我经常刷新DS,并使用SetProcessWorkingSetSize来pipe理内存使用情况。 在我的开发电脑上工作正常。 使用SetProcessWorkingSetSize的优点和缺点是什么?

Solutions Collecting From Web of "使用SetProcessWorkingSetSize的优点和缺点"

SetProcessWorkingSetSize()控制进程使用的RAM数量,否则它不会影响进程的虚拟内存大小。 Windows已经很好地动态控制了这个功能,当另一个进程需要RAM时,可以根据需要交换内存页面。 通过手动执行此操作,会使程序变慢,导致Windows强制将内存页交换回来时导致大量页面错误。SetProcessWorkingSetSize通常用于增加为进程分配的RAM量。 或者当应用程序知道它将长时间闲置时强制进行修剪。 当您最小化应用程序的主窗口时,也可以由旧的Windows版本自动完成。

没有必要捏住这个顺便说一句,你可以使用Process.GetCurrentProcess.Min / MaxWorkingSet属性。

我所见过的这个调用的唯一好例子就是当你知道你的进程将占用很多系统的内存,并且你希望保留这个内存。 你用它来告诉操作系统“是的,我将在整个运行过程中吃掉大量的系统内存,而且不会妨碍我”。

在这种情况下,保留操作系统的默认行为是不好的。 操作系统为每个进程(基本上是其工作空间)分配一个默认的MB内存。 它的资源管理启发式算法不是神谕,所以如果他们发现某些进程吃的方式比系统资源的份额(比如RAM)要多,他们会试图尽可能地回收过多的东西。 对于你的过程来说,这意味着操作系统会浪费大量的CPU(从而损害你的性能),在不需要的时候,通过在你的地址空间中分配内存。

我们发现,对于使用Delphi for Win32 / Win64编写的GUI应用程序,或者使用在Win32 API(GDI等)之上使用大型和重型库的类似方式编写的GUI应用程序,值得一次调用SetProcessWorkingSetSize。

我们用-1,-1参数来调用它,在应用程序完全打开后的几分之一秒内向用户显示主窗口。 在这种情况下,SetProcessWorkingSetSize(… -1,-1)释放大量似乎不再需要的启动代码。 内存很快就会恢复到没有SetProcessWorkingSetSize(… -1,-1)时的三分之一,但不会增长更多。 所以我们已经有效地保存了大部分启动代码(加载和解析配置文件,初始化GUI等)的2/3内存,这些内存可能并不需要。

如果你有一个GUI应用程序,你可以用同样的方法在自己的应用程序上测试 – 只需调用一次,看看有多少内存已经被释放。

即使对于没有GUI的服务器(服务)应用程序 – 我认为在服务器完全加载并初始化之后调用SetProcessWorkingSetSize一次可能是有用的。