Comments: This API appears to be NT only. One thing to try which would be a lot easier than putting SetProcessWorkingSetSize(GetCurrentProcess(), -1,-1) at various places around the code in order to release the working set, would be to use the linker flag: /WS:AGRESSIVE And see what that does. I have personally never attempted this, but it looks to be the way to constantly reduce the working set when in an idle state.

From msdn: "Use /WS:AGGRESSIVE for applications such as services and screen savers that must have a low impact on the system's memory pool. If the speed of your application matters, do not use /WS:AGGRESSIVE without testing the resulting performance." I did a timing test on how long this function took. I was impressed. It took only 6ms to run on my laptop (800MHz 512MB RAM). Taskmanager reported 20MB as opposed 45MB against us - our resident set did get trimmed. I would prefer the control to be with us rather than with the OS.

The logic is when we close a browser, mail, mailcompose, editor windows, I hope to do this.

Fix checked in.

Has someone really tested this? What we essentially says to the OS is "Don't care to keep us in the memory right now". In a memory thight situation, this might cause lots of extra pageing making Mozilla even slower than before. All I see in this bug is a loose idea that it might be worth trying, and it might, but there seems to be no quality testing of the effects (besides system reported RSS) at all before checking it in.

I am sure you already know that SetProcessWorkingSetSize() doesnt really page out the app. Unused pages are put in a list that primed for eviction. If mozilla get used, the pages that get used are removed from the suspend list. Timing analysis showed that such movement of page pointers took 6ms on my 800Mhz laptop. We tested this on Win2k (this will only work on win2k and NT. Wont be enabled on win98). The resident set size is trimmed post window close - logic is that memory needed by that window wont be used immediately following, like a mail compose or mail window. Once you read mail and stuff and close the window, there is no real need for them to occupy physical memory. When we are in high load, it only makes sense that mozilla give room for other apps and hence the resident set trimming makes sense. Of course, if you got any more results, please let us know. By no means is our testing complete and thorough. From the testing done, we believe this is good for the app and the system. Now we would like the open souce community try this and let us know.

Guys, see also bug 108475. The results there are pretty astonishing.

Blake, yeah. We tested this with turbo and were happy to see our resident set reduce when we are turboized and last visible window closes - something like 4MB from 50MB. This makes a happy windows machine.

I strongly suggest we think about this a bit more. I've been wondering lately why it seems that leaving Mozilla stay idle for a while when doing something else makes the system swap like crazy when I start using Moz again. I really think this may be the reason. I always have Moz Mail open, but I often close a browser window when I'm done with it. SetProcessWorkingSetSize gets called with minimum and maximum values of -1. A quote from MSDN: "If both dwMinimumWorkingSetSize and dwMaximumWorkingSetSize have the value -1, the function temporarily trims the working set of the specified process to zero. This essentially swaps the process out of physical RAM memory." In comment #6 is said that it just invalidates the pages. IMO, this quote implies more. I admit that this may be simplified and you might have more knowledge about it. Anyway, let's assume that it really just invalidates the pages (which I don't necessarily find favourable either). In the same time I leave Mozilla alone for a while and work with something else. In my experience WinNT's memory management seems to always try to keep as much physical memory available as possible (this is stupid, when there's plenty already, but that's another case). Thus, it will gladly give the physical memory that Mozilla gave away to the other app I start using (or whatever app needs it). Shortly put: I'd rather see the memory management left to the OS. If it gets low on physical memory, it will swap parts of Mozilla out anyway. If it doesn't, there are much better chances that Mozilla is kept in memory and responds faster. If we really want to do this, we should consider much more carefully what parameters to use and when. Suresh: From the comments I understand that you did a timing test of SetProcessWorkingSetSize(). I believe that the comments in MSDN about performance do not refer to the action of shrinking the working set, but to the overall app performance especially after the shrinking. Sorry about the long comment. I just want to raise more discussion on the matter. I wouldn't mind if you could turn down this comment.

I'm seeing the same on NT4 and it appeared between 0.9.8 and 0.9.9. I'm not seeing it on Windows 2000. I'm not sure it is because of this patch, but it makes Mozilla 0.9.9 really irritating to use on Windows NT4.

I forgot to say that I'm running Win2K Server (Athlon Thunderbird 1000, 512MB RAM) and Win2K Professional (P-III 500, 256MB RAM). Seeing it on both systems.

I think this should be in 1.0..

It should be enough to guard the SetProcessWorkingSetSize with a "isWinVersion >= 5". Seems fairly trivial.

Daniel: Do you suggest that the call should be done only in w2k-> ? I'm seeing the problem on w2k. Making it happen only there doesn't help me or other w2k users that see the symptom.

Oh, I misunderstood you. When you mentioned WinNT, I thought you were talking about NT4. I don't think I've seen it on Windows 2000, but then my Windows 2000 has plenty of memory and I'm using Mozilla much more active then on the NT4 machine where it is constantly swapped out totally unnecessary.

Daniel: See comment #11. I forgot it from the "original" post.

*** Bug 134525 has been marked as a duplicate of this bug. ***

I suggest we remove the call to SetProcessWorkingSetSize() but leave _heapmin() there (I think it isn't guilty)... and do it before 1.0. Here's a patch to do it.

I raised the severity a bit, because in some circumstances this seems to cause excessive swapping also when closing a window. It is most notable on sites that use popup windows to display images etc. In addition, it also causes quick launch performance problems (bug 134525).

We have captured more of the user case and trials with bug 125100 Hence I am going to mark this bug a dup Thanks ere for the patch. I have leaning towards removing heapmin() too as I dont see it doing anything at all. *** This bug has been marked as a duplicate of 125100 ***