From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020212 BuildID: 2002021203 There is a 3-4 second delay when closing windows. This happens with at least mailnews, composer and browser. Mozilla hangs during this time. Reproducible: Always Steps to Reproduce: 1. Open window 2. Close it Actual Results: Window does not close immediately but hangs for several seconds Expected Results: Window should close immediately, browser should not hang. This was also in the nightly from Feb 11th.

Cc'ing dp. Recent occurrence, involving those main windows? Don't know why that SetWorkingSetSize fix would cause this, but it seems suspect.

Yup certainly looks like it. Taking over bug. Nick, I am assuming this doesnt happen this bad before Feb 9. Would be great if we get more info on your system: RAM: Processor speed:

No, it only started happening with yesterday's build (as far as I can remember). My machine is a 256M 800MHz Dell.

QA any help to reproduce this inhouse. I tried this on a Win2k 128MB 200MHz machine and couldn't reproduce it.

jrgm / kerz, do either of you see this?

i don't think i encountered this using 2002.02.11.11 comm bits on win2k, pIII 500mHz --then again, i've recently been focusing on an accessibility test build on win2k, rather than the trunk...

I can't reproduce it per se. I do have a scenario where there is a visible delay in closing the windows, and the CPU spikes while something happens (as in spikes more than any other app does when just closing a window). Set your homepage in the browser to something large (a DOM or CSS spec page [or nsCSSFrameConstructor.cpp for masochists] and then open 10 windows. Minimize all the windows, then restore two mozilla windows. Close the top showing mozilla window while watching the task manager. (1) there is a delay in window closing (or at least a delay in repainting the underneath mozilla window); (2) there is a notable CPU spike; (3) when the window is closed, I see memory (Mem usage in task manager) shoot up to ~30MB, then rapidly down to ~13MB and immediately back to ~16MB [your numbers will vary]. However, I can't say that, aside from point (3), a build from am of 02/08 is subjectively any different in the way it behaves for the above scenario (i.e., we are slow at disposing of those windows). I tried running while dumping out the DEBUG_dp timing info in the patch that was checked in for affecting working set. At most, I was measuring 21 msec for the call to SetProcessWorkingSetSize, although that doesn't mean that there aren't side effects from this. I think a nice Quantify profile of just window closing would be a useful thing to have a look at, particularly to figure out which closing tasks might possibly be deferred so that other windows get repainted without such a long delay.

Those number shiftings in the task manager is expected. 21msec is acceptable. But user is complaining of a 3-4 sec delay. Nick, could we get some more info on your settings. - what applications are you running at the time when you close the window (we are interested in heavy weight processes) TaskManager->Applications is what I am looking for - TaskManger->Performance What does your memory and CPU usage say just before you closed the window - How big is your Swap MyComputer->Properties->Advanced->PerformanceOptions You should see Total size of page file

Jrgm, anyway we can give your build with DEBUG_dp timings to Nick ? Nick, thanks so much for your help so far. Would you be willing to run a build that has timing built in so we can isolate where you are losing this 3-4 secs.

Nothing really happening.

My process status. Unfortunately not able to grab it at the exact time I close the window.

Each spike is a close window action.

(please ignore the first attachment, I sent that before I was ready ;-) My swap is 384M. Yes, I can run the debug build. Let me know where to get it and what to do with it. Cheers.

Whow. Thanks for such a quick turnaround Nick. Your memory usage is 252k (almost close to your total physical memory of 256MB). It is possible for memory compaction that happen during window close to cause pages to get swapped out if there are other processes hungry for memory. This swap out and future swap in as you use other windows, can cause the delay that you are seeing. The key here is other processes that are hungry for memory. jrgm, you can probably similate this if we do close window while we say have a build going...

My memory usage isn't a great deal I'll think you'll find. And I'm not actually *doing* anything significant on the machine (like builds or running CPU-bound processes). All that work is done on a separate Linux box ;-) I just reverted back to build 2002020803 and the problem no longer occurs with that build. Compose and Browser windows go away instantly and there is no "hang". The problem does occur in the latest nightly on Asa's mozillazine page.

Hmm, the build I have is an optimized build with symbols, which weighs in at a mere 95MB. Not sure how to get the whole thing to Nick. Perhaps I can just attach a copy of 'appshell.dll' which has the debug_dp printf's from nsXULWindow.cpp forced on. Nick could download this (about 340KB when zipped) and replace appshell.dll in a build from today. Thoughts?

That should totally work. Can you guys try that. In the mean time, I will do a optimized build with the timing enabled (no symbols), just in case.

Okay, here is a zipped copy of appshell.dll, which has the debug printf's forced to be on. Save this attachment as 'appshell.zip', and then extract 'appshell.dll' from the zip file. Then, in a build from today (optimally, might work in a relatively recent build if no interfaces changed) rename .\components\appshell.dll to .\components\_appshell.dll, and then copy the new version of appshell.dll into .\components\ Then start mozilla from a command line, with ".\mozilla -console", to get a console window. Timing measures of the the calls to _heapmin and SetProcessWorkingSetSize will be shown in that console when a mozilla window is closed.

Ok, I did what you said. The output looks like this: stdout directed to dynamic console stderr directed to dynamic console DEBUG: HeapCompact() success - 0 ms DEBUG: Honey! I shrunk the resident-set! - 2714 ms DEBUG: HeapCompact() success - 0 ms DEBUG: Honey! I shrunk the resident-set! - 4120 ms DEBUG: HeapCompact() success - 0 ms DEBUG: Honey! I shrunk the resident-set! - 2780 ms The first shrinkage is a new empty browser window being closed The second one is a browser with 4 tabs of various websites loaded being closed The third one is mail composer (nothing entered) being closed

Additional. The first window opened closes instantly but an new window (ctrl-n) closes with this delay. The main problem is the apparent hanging (window remains painted on screen and doesn't go away). stdout directed to dynamic console stderr directed to dynamic console DEBUG: HeapCompact() success - 0 ms DEBUG: Honey! I shrunk the resident-set! - 777 ms DEBUG: HeapCompact() success - 0 ms DEBUG: Honey! I shrunk the resident-set! - 1186 ms DEBUG: HeapCompact() success - 0 ms DEBUG: Honey! I shrunk the resident-set! - 1214 ms DEBUG: HeapCompact() success - 0 ms DEBUG: Honey! I shrunk the resident-set! - 1031 ms First and last value is the first window being closed Second and third value is the second window being closed. Not sure if these stats really illustrate the problem, as I said the main problem is a visual hanging of the window where it remains painted.

Nick that is of incredible help. As we suspected, it is the resident set mucking that takes so much time on your machine. Why is the interesting question ? Esp since on lesser machine (128MB 200MHz) it seem to take not more than 20 ms. Ccing Garrett for any clues.

Possibilities: Should we not shrink the resident set until say five seconds after the window closes? Should we shrink it gradually, say a couple megs every few seconds?

OS does the shriking for us, when we envoke the system call. We could try using a timmer.

I am going to try the timer trick next and see how it feels.

On window close, we set a 100ms timer. Heapcompaction happens on the timer.

Nick, could you give this appshell.dll a try. Instructions for using it is the same as befor from jrgm. Thanks.

Confirming om OS X build ID 2002021403 Very, very slow opening and closing of windows, especially new windows invoked by the window.open command on pages. Takes about 3 to 4 seconds on a G4 450 Mhz. 512 MB Ram Compared it to NS 6.2.1 wich only takes about a second to open new windows.

Okay, fair enough comment, except the particular code under discussion in this bug is only executed on win32 platforms, since it is calling particular win32 APIs (and even then, only if they are available on the user's OS version). So, the OS/X issue would be something separate from this bug. If there isn't a bug open that fits your description/experience, then please file one (although I expect that a bug already exists).

filed bug 125758 for comment #27 Mac OS X issue.

Suresh, I tried your appshell.dll but I saw no difference. The first window opened closes without hanging. Subsequent windows still hang. Sorry ;-(

I was thinking of a delay more on the order of 1000ms. Would that help?

I use 0.9.9,under NT4, and stopping windows is too much long !

This looks very similar to bug #127634. I have this problem all the time on my PC (Win NT 4 SP6, 384M RAM, Athlon 650 processor) running 0.9.9. I often open 8 to 10 windows, and when I click the 'exit' menu item, it can take as much as 30 seconds for all windows to close. Very irritating. Does anyone know whether this bug is fixed in a newer nightly build?

IMHO it is the same bug (a dupe). And, I can categorically tell you that this problem stil occurs on my latest nightly build (2002032408).

I can confirm this on a Win98 with 512 MB of RAM. Closing the Windows hangs everything for 3-4 seconds (although the taskbar icon vanishes before the freeze).

Now wait. This fix is a noop for win98.

Hello, I have the same problem with Mozilla 0.99 at home (on a 700 Mhz Athlon with 192 Mb RAM under Windows 2000 Professional). Mozilla 0.98 was ok, so this is a serious regression (and _really_ annoying in everyday usage). This happens when closing any kind of window (browser, mail...) ; one must wait several seconds before Mozilla wakes up again, redraws itself and accepts user input. It looks like some heavy garbage collecting is done (I mean, it's the impression it gives from the symptoms, I did'nt investigate in the source code ;-)). For me, it's part of the two or three big problems that make Mozilla not completely ready for every end-user. Antoine.

Ok. Since I cant reproduce this inhouse, and so many of you are seeing this, I am going to eliminate the working set reduction that happens on window close. patch follows...

Comment on attachment 76752 [details] [diff] [review] Stopping working set reduction on window close In case review needed, I reviewed.

Which next build will the patch be included in?

Well, next steps are to get another review (sr), then get approval to land (a=) and then find a time to land. Should likely happen in the next few days; stay tuned to this bug, and dp will mark the bug FIXED when he lands this patch.

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

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

Nominating for adt approval.

We'll look at accepting this one, once it has a sr=

I've built an optimized build including this patch. Seems to improve performance a *lot*. Sr= please anyone?

Ccing alecf for sr=

Comment on attachment 76752 [details] [diff] [review] Stopping working set reduction on window close sr=alecf oh baby this was driving me nuts. That said, I'm sorry to see the actual functionality go away - this is Yet Another Idle Function - i.e. work we could be doing when we think the user has been idle for a while. I really think we ought to consider adding an idle-detection service of some kind. This is also something I would have liked to see happen whenever I hit "sleep" on my notebook (Because apps which take up less memory take less time to restore from a sleeping state) also, is this something that can happen on a background thread, instead of killing it entirely?

Before anyone re-implements this, please read my rant from bug 123729. Thanks :)

adt1.0.0+ (on ADT's behalf) approval for checkin into 1.0.

Comment on attachment 76752 [details] [diff] [review] Stopping working set reduction on window close a=asa (on behalf of drivers) for checkin to the 1.0 trunk

Alec, I think turbo-last-window close would be an ideal spot for this. But I really think we need atleast one milestone to try this out. Let us see.

Question? Was too much of fix backed out? From the data above and code inspection it seems to me it was setProcessWorkingSetSize causing the bulk of the delay. How about leave in the heapmin() and just back out the os call (it marks all pages of the process idle, thus first candidates to discard or page-out).

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

Fix checked in monday @ 9pm california time (PDT). Ere Maijala is verifying the fix (thanks Ere). Sam: here are my reasons for backing out heapmin too - With my testing I didn't see heapmin() reclaiming any memory at all - Thought we need to do this at a different place rather than on every window close

Got today's build: 2002041003 and initial testing looks good. Windows close as quick as one might expect. Good work!

Thanks Nick. Closing FIXED.

Marking this verified, although there seems to be a similar problem when minimizing a window. But it's place for a new bug I think.

The minimizing problem seems to be a Windows feature. Other programs have same symptoms. Case closed.