I've done a little more reverse-engineering, and:
1) it seems like the information retrieved with GetSystemInfo() in EmptyWorkingSet() isn't used at all - weird to make the call, then.
2) EmptyWorkingSet does an NtQueryInformationProcess() (which SetProcesWorkingSetSize() doesn't), and then sets QuotaLimits.MaximumWorkingSetSize and QuotaLimits.MinimumWorkingSetSize to -1 (the fields that SetProcesWorkingSetSize() sets).
3) as best as I can tell, the code in NtSetInformationProcess() that handles ProcessQuotaLimits does an early-out if both those fields are set to -1, and calls a kernel function to - you guessed it - trim the working set. There also seems to be checks to ignore structure members that are 0, so even if I'm mistaken about the early-out, the zero-ed out structure that SetProcesWorkingSetSize() uses should be equivalent to EmptyWorkingSet()'s "pass in the old values". I could
be wrong, of course, and there's quite a bit of code going on... but it seems unlikely.
For the rest of your post... the maximum memory saving you got was 100kb? Waaauw. Even if you had 20 processes that were trimmed like that, you'd save a whopping 2MB of memory. Add to that that you risk paging out a crapload to the pagefile (SLOW!), and at the very least you'll have discarded memory that must be re-loaded from unmodified files (slow, but at least faster than diskwrite + read).
And keep in mind that you can only trim the working set this way, it doesn't change the amount of memory the application actually hogs (sure, you might get that memory flushed to the pagefile, but as soon as the app starts using it again, it will re-enter the working set, along with a lovely disk I/O penalty).
For fun, I tried trimming firefox - too bad it hasn't been running an entire day and gobbling up 800 megabytes as it tends to end up doing
. The three screenshots are before trim, right after trim, and after looking through the 6 active tabs again (no scrolling, no loading of new pages, no pressing anything except activation each of the three tabs).Rambooster. Junk?Rambooster. Junk?Rambooster. Junk?
Now, if you look at all three pictures, you'll say "oh wow, my point is valid, see how working set remains small even after you start using it again!" - but check out the "available memory" column in the main window instead. Yep, we get a temporary increase of ~9MB, but as soon as I start using FF again, that turns into a ~7MB pessimization
compared to before I ran the trim!
For fun, I closed FF, saving tabs, then re-launched it, and waited for the youtube video I had open to buffer fully. The result is the following screenshot... ~210MB saved. Have I made my point yet? (Oh yeah, that also involved starting an extra process - xplorer^2, I think).Rambooster. Junk?