Reduce application working set.

[objectref]

Hi,

i found on the net something that it has to do with the large
working set of a .net application, describing the process of
the CLR loading and all this stuff.

It seems that every time CLR needs memory, it requests a bit more
than it actually needs so with the below simple code we can
"trim" the extra memory and keep the working set down.



public static void SetWorkingSet(int lnMaxSize, int lnMinSize)
{
System.Diagnostics.Process loProcess =
System.Diagnostics.Process.GetCurrentProcess();
loProcess.MaxWorkingSet = (IntPtr) lnMaxSize;
loProcess.MinWorkingSet = (IntPtr) lnMinSize;
//long lnValue = loProcess.WorkingSet; // see what the actual value
}



I made some tests of a software of mine that we work here (in-house) in my
company
and i saw that from 30+ MB of memory that my app needed all this time,
with the above code it occupied less than 10...

To accomplish that, i was "forced" to call this routine in every form
load/unload event
and the working set really kept down this way.
In theory, all this code does is to call the repsective Windows API function
so it in turn
trim the application workign set.
If it cannot trim down to the values specified, it just do the best it can.

I was wondering if this will cause any runtime (or other) problems,
can anyone help on this ??

Thanks in advance,

objectref

 

[Michael Nemtsev]

Hello objectref,

What's the reason for trimming working set?

The problem is that u can end up with the performance degrade, when the set
is too small and process request additional memmory pages that sould be taken
from swap

o> Hi,
o>
o> i found on the net something that it has to do with the large
o> working set of a .net application, describing the process of
o> the CLR loading and all this stuff.
o> It seems that every time CLR needs memory, it requests a bit more
o> than it actually needs so with the below simple code we can "trim"
o> the extra memory and keep the working set down.
o>
o> public static void SetWorkingSet(int lnMaxSize, int lnMinSize)
o> {
o> System.Diagnostics.Process loProcess =
o> System.Diagnostics.Process.GetCurrentProcess();
o> loProcess.MaxWorkingSet = (IntPtr) lnMaxSize;
o> loProcess.MinWorkingSet = (IntPtr) lnMinSize;
o> //long lnValue = loProcess.WorkingSet; // see what the actual value
o> }
o> I made some tests of a software of mine that we work here (in-house)
o> in my
o> company
o> and i saw that from 30+ MB of memory that my app needed all this
o> time,
o> with the above code it occupied less than 10...
o> To accomplish that, i was "forced" to call this routine in every form
o> load/unload event
o> and the working set really kept down this way.
o> In theory, all this code does is to call the repsective Windows API
o> function
o> so it in turn
o> trim the application workign set.
o> If it cannot trim down to the values specified, it just do the best
o> it can.
o> I was wondering if this will cause any runtime (or other) problems,
o> can anyone help on this ??
o>
o> Thanks in advance,
o>
o> objectref
o>
---
WBR,
Michael Nemtsev :: blog: http://spaces.live.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[objectref]

Maybe becauce when you run one managed app is fine, but if you
have 10 of them running it may become a problem...
I know that OS is capable of taking the extra ram when it needed but
just a thought...

 

[Nicholas Paldino [.NET/C# MVP]]

I agree with Michael. Yes, when you have 10 apps running, it is better
to let the OS and the CLR work in conjunction to prevent degredation from
the apps. The CLR will cede memory when the OS demands it. You shouldn't
have to touch it.

 

[Willy Denoyette [MVP]]

There is absolutely no reason to do this (other than for diagnostic
purposes). It's the task of the OS to trim working sets of running
applications, and only the OS is able to do this in a correct way, it know
the usage pattern of the loaded pages in RAM and will only trim those pages
that haven't been touched recently. When doing this from your own code, you
may throw away pages that you'll need directly after you have trimmed, that
means that you will incur a performance hit because of page faulting.


Willy.






| Hi,
|
| i found on the net something that it has to do with the large
| working set of a .net application, describing the process of
| the CLR loading and all this stuff.
|
| It seems that every time CLR needs memory, it requests a bit more
| than it actually needs so with the below simple code we can
| "trim" the extra memory and keep the working set down.
|
|
|
| public static void SetWorkingSet(int lnMaxSize, int lnMinSize)
| {
| System.Diagnostics.Process loProcess =
| System.Diagnostics.Process.GetCurrentProcess();
| loProcess.MaxWorkingSet = (IntPtr) lnMaxSize;
| loProcess.MinWorkingSet = (IntPtr) lnMinSize;
| //long lnValue = loProcess.WorkingSet; // see what the actual value
| }
|
|
|
| I made some tests of a software of mine that we work here (in-house) in my
| company
| and i saw that from 30+ MB of memory that my app needed all this time,
| with the above code it occupied less than 10...
|
| To accomplish that, i was "forced" to call this routine in every form
| load/unload event
| and the working set really kept down this way.
| In theory, all this code does is to call the repsective Windows API
function
| so it in turn
| trim the application workign set.
| If it cannot trim down to the values specified, it just do the best it
can.
|
| I was wondering if this will cause any runtime (or other) problems,
| can anyone help on this ??
|
| Thanks in advance,
|
| objectref
|
|
|