If I minimise the Mozilla browser window on my machine, and leave it for a while, - a couple of hours or more - when I come to restor the window to maximal size afterwards, the Windows titlebar appears, but it can take 20 seconds or more for Mozilla to redraw the rest of the page. In build 2001041804 but its been around for a while.... I'm running Win NT 4 service pack 5

Sounds like mozilla is being swapped out to disk... how much RAM do you have?

I'm seeing this as well on 2001041920 Win2k with 256 MB of RAM. Confirming, but I'm not sure if this is really a valid bug - I'm not sure that this doesn't happen with other applications as well.

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

Pasting my comments from bug 80586: If I leave Moz sitting idle in the background of my desktop for a longish period (+/- 30 mins) and then raise it, it takes about 30 seconds to become responsive again. Mad disk activity (swap) before it becomes usable again. Is this perhaps just Win2K's dodgy VM system ? I would say yes since the OS should handle bringing apps back to life after the memory has been swapped off somewhere else, but all other apps under windows are basically immediately responsive after sitting idle for a long time. Is Moz's footprint to big to have state kept long enough ? Apps like outlook have just as big a footprint, yet are almost immediately responsive on raising after long idle times.

I recall talking to someone about this. The problem may be that Mozilla uses lots of files (gif, css, js, etc) instead of being a single binary. All these (especially the images) get swapped out of memory much more aggressively than binaries do, apparently. And take a while to bring back.

Actually, windows 2000 aggressively swaps out libraries too. The problem isn't that they get swapped out, it's that mozilla needs too many of them before it can resume functioning. I have no idea to whom this bug could be assigned...

->Apps

nav triage: moving to m1.0 since not sure if this happens for lots of users.

don't think I'll get to this by mozilla1.0, marking mozilla1.2

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

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

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

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

I have read other comments. There could be some Windows 2k optimization that helps the matter, like not swapping dlls etc. Does anyone else think that fiddling with w2k can help?

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

This is getting duped a lot. Updating summary to be more self explanatory.

It happens on NT as well if we can't find this optimisation, I don;t think anyone else will. Maybe since each mozilla needs so many files, is it possible to join them to a single file, with an index, and only use that ? Might be a good idea to stop fragmenting peoples file systems as well. This is annoying though especially since it takes away some of what quick launch gives us. Please fix it :) it stops me running mozilla regularly.

-> default assignee

Hi all. My first time posting on Bugzilla, so be gentle. I'm not much of a programmer, but I've been doing some testing on this problem. I collected a ton of performance counters on several different programs that had all been sitting idle for 30 minutes: Acrobat Reader 5, Netscape 4.79, Mozilla 0.9.7, Star Office 6, and Winword 97. To begin with, I timed how long each program took to become responsive after this time period. Mozilla was by far the slowest at around 45 seconds. Acroread was next at about 25 seconds. At first I thought it was page faults, but Acroread generated a mind boggling 1943 page faults when re-activated, compared to only 480 for Mozilla. Then I thought it might be # of handles and DLLS opened that had also been paged out. However, ProcessExplorer tells me that StarOffice had 809 handles and 74 non-system DLLs opened. Mozilla had 62 non-system DLLs and only 176 handles. I checked a number of other things, such as # of threads and CPU %, none of which was illuminating. Then I discovered that when Mozilla was re-activated, it's working set (allocated bytes, I believe this means) went from 2.4MB to 22MB! Conversely, the next biggest jump was winword which went from 2.1MB to 6.5MB. I don't know if this is particularily enlightening, but it seems to me that Mozilla is all of a sudden trying to grab a lot of memory when it wakes up. If you real programmers want me to continue testing, I'll be happy to do so. For the record, I'm using a 600Mhz Pentium III with 128MB RAM running Windows 2000 Sp2.

dp, what do you think of the data in comment 19?

Thanks Turin. This is my guess: The 2.4 MB that we see when mozilla is *inactive* is the amount that is truely used in memory (all usage - swapped out pages). Thus when reactivated, all the pages that are required get swapped back in -> 22MB. So the jump isn't the interesting part. The fact that 22MB is used is interesting. But we know mozilla does take that much memory. The slower reactivation could be painting happening slowly + time required to swap in 20 MB (22 - 2.2 MB)

45 seconds on a P3/600? That doesn't sound normal. Did you mean 4-5 seconds? (Which is still longer than I've ever seen on my P3/700) Could be thrashing. How much memory is available when you do this?

4-5 seconds is really interesting. It could be good to know Your windows configuration. Or can anyone find out if the difference is caused by using XP instead 2000: Jan

Peter... I did in fact mean fourty-five seconds! Upon further tests that was a high number, but it never gets below twenty-five seconds. It is true that this only happens when Mozilla is paged out. I also understand about working sets now. However, more tests have shown me something interesting.. I loaded my system down with a bunch of applications that all have about the same memory footprint when they are first loaded, including Netscape 6.0, Outlook 97, IE5.5, StarOffice 6.0, and Mozilla 0.9.7. I minimized them all, then played around with Photoshop to ensure that they all got paged out. When they were all down to about 2-5MB working sets, I started maximizing them and seeing how long it took for them to become responsive (by which I mean that I could click on a menu and the menu would open right away). Mozilla was definately the slowest and I noticed that when it was maximized, it did not become responsive until it's working set had grown to almost its original size; 19MB in this case. Even Netscape 6 which started with 27MB and refused to give it up for the longest time, started responding promptly when it had 15MB. StarOffice needed 10, IE needed about 9, & Outlook only wanted 6.8MB. IANA Real Programmer, but this seems to suggest to me that Mozilla cannot function properly unless all of its various DLLs and other resources are loaded into memory, whereas other software is not so particular about having all of its resources in memory. I hope this helps in some way. I have access to an XP Pro system, so I'll try this under XP as well and let you know the results.

Not sure who should get this. Cathleen, could you suggest someone?

Swapping in 22MB and potentially swapping out 22 MB wouldn't cost 45secs. I am guessing the delay is more involved with the painting.

If it helps more, this is exactly what I experience: When I click on the minimized Mozilla icon on the task bar, the outline of the window and the title bar come up immediately. After about ten seconds, the menu bars are drawn. After twelve-fifteen seconds the rest of the window is drawn. If I initiate any action around this time, such as clicking on a menu or hitting a button, it takes about five seconds to respond. Only after a minimum of 25 seconds have passed will the application be completely responsive.

DP: What part of 25 seconds do you think painting would take? I'm guessing a small fraction of 1.

Peter: A small fraction is what painting *should* take. The time of 20 secs to redraw after reactivation is time-for-swapping-in-memory + time-taken-by-redraw We think either of these shouldn't take that much time. So we got to account for which of the two is taking more time and why ? My guess is more on the time-taken-by-redraw

I can easily notice the slowness, after doing a build on my machine. Bring up a minimized window is noticibly slow on a 1 GHz machine... Maybe someone can try to create the slowness situation this way.

I still have no idea who should get this.

I've seen the same thing happen when Mozilla sits idle in the System tray. Its making Quick Launch useless to me. I'm sure its a coming to life problem. It happens quite common on my PII 333MHz with 192Mb memory

->hewitt for triage

I confirm this bug. Windows XP, 1Ghz Celeron, 512MB RAM (!!!). Memory usage normally never exceeds 200-300 MB. Mozilla "wakes up" very slow anyway with lots of disk activity. Tried to change "Large system cache" - no change noticed. Don't blame MS this time, please ;-))

Are people still seeing this on current builds under NT/Win2k/XP? Blake made some changes that should help this. Also, is this only happening with QuickLaunch?

I see this sometimes. I don't think it has to do with QL but our painting/view manager code. Frequently the chrome will show up first and then it takes time (during which the app is hung) for the content area to fill in.

I see the following: window's frames appear quickly but content is repainted very slowly, especially in Mozilla Mail window.

I still see this on win2k, 256MB RAM. Outline comes up fast, but content takes ages to get filled in. Its not as bad as it used to be, but still painful - around 10-15 seconds to come properly back to life

cc varga

I guess, window outline comes up real fast because it is painted by native window manager. For app menu we need XUL, for content area HTML, ... so all this stuff need to be swapped in.

nominating for MachV, ->morse

nsbeta1+ per Nav triage team, Nav2, ->1.0

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

Please update this bug with an [adt1] - [adt3] impact rating (or take it off the list if it doesn't even rate adt3.) Thanks!

Setting OS to All because it happens in all windows versions. I really think this bug is INVALID/WONTFIX because it's caused by the bad VM design of Windows. Windows swaps out all inactive applications even when there's no pressing need.

i don't think this sould be marked INVALID/WONTFIX because even Corel Draw swaps in faster, and even after mozilla is swapped in it stays unresponsible/unuseable for a few moments, while corel draw for example is ready to work but mozilla takes a signoficant time longer to be fully work-ready. i personaly don't think this is the only fault of the bad VM of windows, i think there is more than just that.

killing os all. all should be used when multiple os families experience a bug, this is limited to win32 so all is inappropriate. I see no references to w9x so Windows NT is the oldest version of the win32 family where this problem happens which means it's the os we should report..

sorry, it affects win98se too. i'm using Windows 98SE and i have this problem too. so all windows versions should be correct. Pentium3, 650 MHz, 192 MB RAM, Windows 98SE

This is *very* annoying bug, because bringing Moz from traybar takes longer than launching Moz 100% from death ;). Usually it takes some 40-60, and that is very long. This is very blocker for 1.0 release, and almost completely makes "Turbo" mode unusable. Athlon 600MHz 256MB ram Windows XP

converting nav2->adt2

Like in #49 I have to say this is really annoying. It takes up to 60s wake up so if you're working with other programs, it's almost every time that Mozilla got paged out and is somewhere in Nirvana. Quickstart is useless, the normal startup time (which is long already) is faster. I remember this not being serious in earlier builds let's say before 0.9.7 but I'm not too sure about that. Some people I made use Mozilla already went back to IE just because of this :( PIII-784Mhz 384MB Win XP Build ID 2002031104

It's Windows VM that is to blame making "Quick startup" very slow. Try disabling paging file (No paging file at all). Everything works excellent! I've got 512MB on my Windows XP Pro machine and don't use pagefile.sys at all. It proves that VM managagement swaps out most of Mozilla code/resources...

Not to beat a dead horse, but, I must concur with previous posts. Mozilla is taking way too long to restore. This can not be the OS (entirely) because this is the only program that I have this problem with. Lotus Notes is one of the biggest hoags that I have seen and it restores in seconds (< 5sec at worst case). This is the main reason that I have not switched to Mozilla exclusively. IE just runs better right now. I hope that this can be resolved since I find Mozilla a much better feature rich platform then IE.

I think it's way too easy to just blame windows again. Mozilla is the only program that takes THAT long to wake up. I work with Corel DRAW, OpenOffice and Photoshop at the same time and all three of them come to live considerably faster than Mozilla alone. Sorry for just confirming this bug but I think this is very important cause most of Mozilla-Users are Win-Users who are far away from having enough ram to work without VM. And, of course, it's so much easier to switch back or stay with IE if you don't care about Microsofts behaviour.

Just wondering if things are a little better on today's builds : Apr 09 2002 Last night I disabled resident set reduction and I am thinking it might have an effect on this modulo high memory pressure from other apps. Let me know.

I'm not quite sure if it helped. I took two times. One starting up from minimized state, one completely from quicklaunch up to menus and stuff reacting properly. minimized 25s (2002031104) - 6s (2002040903) quicklaunch 40s (2002031104) - 60s (2002040903) Hopefully this was the right build with the named changes implemented since there were many nighly builds and I just took the latest.

I don't know whether this is important, but Mozilla does take longer than other OS X apps to become active once it's been swapped out of memory. (I record around ten seconds on my G4 450, but OS X in general is slow on a G4 450, so I didn't really notice till now)

There were a couple of comments about this happening while using QuickLaunch, but is everyone seeing it *only* in QuickLaunch (i.e., it doesn't happen with QL disabled)?

I'm not a guru, but I want to try to provide an explanation. I guess that the problem here is the excesive modularity of Mozilla (xpcom for everything). This causes that in order to do minimal tasks, the processor is jumping allover the place executing differente support components, like for getting StringBundles, or accessing a file on disk, etc. I don't know how can this be solved. Perhaps controlling the link process in order to keep critical sections together. Sorry if what I've just said is all crap, or too obvious.. :/ I'm no expert on this. =)

Could the swapping to disk just be (optionally) disabled?

Let me share my 2 cents worth. Other apps' interfaces are drawm by Windows itself. In Mozilla, only the titlebar is drawn by Windows, the rest is drawn by Mozilla itself. After long periods of inactivity, Windows resurrects Mozilla quickly, as evidenced by the immediate showing of the titlebar. But since most of Mozilla is swapped to disk, it takes time for Mozilla to redraw itself. Other apps are unresponsive also, but their GUI is shown immediately because they do not have to draw their own interface.

this is a pretty serious bug - worse on mozilla than other large applications. also, though, for mozilla's original goal of being "small & fast", it's awful large! it takes up more ram than lotus notes or my java swing applications, both known for being huge. this bug will likely turn many potential users away (and back to IE) if it isn't fixed :(

Does the fix for bug 125100 affect this?

Yes. Fix for bug 125100 could do anything from not affect this to help this. Wont cause any worse behaviour. My guess is it might help it in most cases.

I think a lot of this is due to the Mark/Sweep GC mechanism. Once most of Mozilla has swapped out, a GC cycle will touch most of that memory and require it to be read back in before much of anything can be done.

Some benchmarks: After doing some rendering & other memory consuming things WinXP taskmanager shows Mozilla mem usage 1304K. ("Quicklaunch" only active) Startup time: Titlebar appears: ~15 seconds Rest appears: ~20 seconds. For comparison, Nutscape 4.77 startup time is ~10 seconds. While RC1 starup times is lots faster than 0.9.9's 40sec, but i'd still like to see it pushed at 10 sec...or faster. Athlon 600MHz 258MB Ram WinXP Pro

I just thought I'd note that Mozilla is the only app I've used to exhibit this behavior under both Win2k, WinXP, and MacOS X. And this includes development environments, graphics packages and other enormous programs on the same memory usage scale as Mozilla. I have a 1 Ghz Athlong with WinXP, and 733 Mhz with Win2k, and a 500 Mhz with MacOS X. (All with 256 megs of ram.) I don't have quicklaunch enabled on any of them. Leaving Mozilla inactive for anything longer than a few minutes and it takes between 30 and 60 seconds for it to become responsive again, on all three platforms. (Oddly, Mac OS X is the fastest, even on the slower computer. But not by much.) This is a serious problem, and I've had to mostly stop using Mozilla at work, because I've grown tired of explaining to co-workers looking over my shoulder that I'm waiting for Mozilla to wake up, again.

My system: 1 GHz Athlon C, 512 MB RAM, WinXP The slow maximize bug can occur after just a few seconds: With or without QL activated, Mozillas RAM allocation drops from about 20+ MB to 3.5 MB after minimizing all Mozilla windows. Copy large files (400 MB+) and restore a minimized Mozilla window during the copy process takes some minutes longer and it takes about 30 seconds up to 3 minutes (!!!) to see the restored window and work with it. This is a nice way to see this issue instantaneous. Killing the process and restarting Mozilla is way faster than restoring a window (like others here experienced). With 1.0rc1 there is a noticeable speedup but restoring a window shouldn't take longer than killing the application and restarting it. Can't Mozilla be forced to keep everything in memory when minimized?

Then you'll get people complaing that Mozilla is slowing down other applications when minimized because its not release that memory.

I am unable to duplicate this. Tell me what's wrong with my testcase: - computer is P3-850, 256MB ram, WinNT, recently defragged - Mozilla build 2002-05-01-branch, installed browser-only, Quicklaunch active - I load NT's taskmgr.exe and set it to display Mem Usage *and* VM Size - on initial load, mozilla.exe uses 19MB/13MB of memory, respectively - I load multiple pages, get the mem usage up to ~40M, then minimize all - mozilla.exe goes to 18MB/25MB - copying large files, loading other apps, waiting 15min, etc. all fail to reduce the Mem Usage stat (in ram) below ~18MB Mozilla is immediately responsive when I unminimize any window - I close some of the browser windows and it goes to 2MB/22MB - I copy a bunch more files, but the File Cache never goes above 50MB - *NOW* Mozilla has to reload from cache but it still takes less than 5 sec. Are you sure y'all aren't just suffering from fragmented swapfiles? I'll keep testing it, and try to get more than "just" 22MB swapped to disk...

@ #69: Isn't that what quickstart should be? holding everything in memory so it's faster accessed? what else is that function good for? @ #70: It could be XP specific. XP uses all free memory as a disk cache. Mozilla frees up some memory -> Windows XP grabs it for disk caching purposes while copying large files -> Mozilla needs a lot of time to restore its windows. I don't know if 2k uses the same technique. Could someone check that?

You are correct, Windows 2000 and XP both more aggressively cache disk accesses than previous version of Windows, but I don't think that's a big issue. Keeping Mozilla resident would solve the problem for Mozilla. That risks being labeled a bad neighbor. By not relinquishing the working set when Mozilla is not in use will cause an overall degradation of performance, since this will effectively reduce the size of the disk cache. So we'd be improving Mozilla at the expense of other applications. If I have Mozilla in the background doing nothing I don't want it degrading my overall system performance uneccessary. I think what other posters have mentioned about fragmented swap files would be good for people to investigate first. If your swap file is able to grow, and your disk is fragmented this can have a drastic performance hit. If I run an application on my system that allocates large amounts of memory, I can easily get Mozilla swapped pretty much completely to disk. On my system it can take up to 10 to 15 seconds to get Mozilla responsive after it has been completely swapped out. If I do something that causes a garbage collection cycle this time can be doubled. This is on 733mhz laptop with 384megs of RAM, with I'm sure a rather slow hard drive. I have defragged my drive and my swap file is fixed. If you're system it taking longer then you may need to defrag or check into the transfer rates of your hard drive. You?ll need to reduce or eliminate your swap file, defrag, then set the size again. What shaver is working on for bug 66381 is probably the best solution, this should reduce the amount of pages we touch during a GC cycle.

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

#71 Also happens on NT as well Do we know for certain thats what the problem is ?? If its not so hard to put together a build which doesn't release memory when the window is minimised or Moz is being launched from QL, then maybe that would be a good idea and it could be tested in the way described in #68.

It seems to me that 1.0rc1 made Mozilla "longer" responsible. I also think Mozilla is more agressively trying to be responsible in the first place, but takes longer to open menus and stuff once seeming to be finished with paging in. So the look&feel should be faster for the average user. Once Mozilla is paged out completely it seems to me it even takes even longer to wake up than 0.9.9. 3min like in #68 is quite normal. One should wonder about the sense of quicklaunch then... Since I am working with memory-consuming apps all the time and need to look up things in the web/ check mail in between I'm almost always waiting for ages for Mozilla to wake up. I think this is a very serious structural Problem of Mozilla drawing itself and I don't think it can be solved soon without keeping mozilla resident in memory which would of course be very unelegant. I never thought so but I'll probably be leaving Mozilla as browser since I'm just tired of staring at the screen and then (cause I was to impatient) seeing 4 Mozilla windows popping up at once, trying to use one of them and close the others and then wait again for ages for these tasks to complete. My disk is on heavy pressure all this time. I can't reproduce this behaviour at all on linux or osx like in #67 though on osx (G3-600) the performance is sluggish overall but that's another story... I dunno that much about bugzilla but please, the ones who are in charge: This bug is definitely very serious and could be the one and only reason to drive users away from mozilla so please adress this to high priority.

It was the first anniversary of this bug last week! :) Seriously though, this is how long it has been around. Its not a new thing, and it certainly not improved at all in any build I've used since (the milestone ones). Please see this fixed before the release

I know y'all are probably tired of hearing from me, since I don't have a problem! Still, I thought it would help to give a little more description of what I see: - when I minimize Mozilla, the NT Task Manager shows it aggressively swap to disk (i.e. "VM Size"). So Mozilla is being a "good" app by not fighting to stay in RAM. - after a moment, the code slowly starts swapping back into RAM (i.e., "Mem Usage"). This probably happens because I have enough unused memory; my "Commit Charge" is typically ~160MB, and I have 256MB installed. Can the W2K and XP users try to duplicate this, please? You need to open Task Manager and change the default Processes display so that it includes "VM Size". Also, is there someplace in the builds where one can specify the memory "priority"? If so, then maybe these settings needed to be adjusted so that the important parts of Mozilla will 'try harder' to stay memory-resident.

On Win2k, when the problem occurs, the memory is: Mem Usage, VM Size (sizes are approx): 100k,19000k On clicking the toolbar icon to bring focus, it goes to: 9000k,19000k On actually trying to browse (e.g. click refresh) it goes to: 20000k,20000k So.. unless the VMSize isn't reduced as programs are swapped in, it's new memory being allocated/program code being loaded that causes the disk churn/slow response.

The VM isn't affected by whats in or out of the paging file. The VM size is the amount of memory committed to a process whether it currently resides in physical RAM or is store in a swap file. This would be expected to remain somewhat stable when restoring an application. The churn is caused because you're paging in almost 20 megs of data by the time you're done with refresh. And the time required to page this in, is dependent on the throughput of your harddrive and controller, and how fragmentted your paging file is, whether it has to swap out other data to accomodate the requests. If the OS has to reduce other working sets, it may end up writing out 20 megs of data as well as reading it. On my system it takes about 30 seconds to restore Mozilla when it's been swapped out and can recover the memory from non-workingset sources.

David B., I don't think your description of "VM Size" is correct. If it represented the size of the entire working-set, then it would always be equal-to or larger than the "Mem Usage" stat, but it isn't (on NT at least). So, I still think it represents the amount of virtual-memory in-use by the process. This makes it very interesting to note that the "Mem Usage" stat grows without "VM Size" being reduced. Perhaps Mozilla is releasing memory needed for on-screen display, then re-requesting it when unminimized? Also, when inspecting (normal) apps like Outlook, they don't surrender nearly as much code to VM as Mozilla. For instance, when I minimize Outlook it maintains 9MB in RAM, my financial calculator program maintains it full 5MB (w/o surrending anything to VM), while Mozilla maintains just 2MB (the other David's comment #78 was just 100k!).

I've just been playing.. When I load the system, eventually the Mem Usage figure goes down. The VM Size doesn't appear to go up though but remains stable. If you also view the Page Faults count, when you click mozilla to bring it to focus, you get lots of page faults. I thought this was a count of how the VM system had to page data in and out of RAM/Swapfile. If so then this backs up #79. Interestingly, I've been running IE6 in parallel (iexplore), and that had a size of 6500k,5500k. which reduced to 1300k,5500k. On clicking, it does the same and the Mem Usage goes back to 6600k,5800k So... I guess it does similar, but is just swaps back in much faster than Mozilla due to smaller memory footprint. My question... why is mozilla so large? I thought it was supposed to be a 'lightweight' browser, for use on anything from embedded devices upwards. Yet IE appears to have a much lower memory usage. I guess integrating mail/news/composer/irc etc has it's penalties.

David: It's not that Mozilla is particularly large, but IE 'cheats', since much of it is integrated into the OS.

Re: Comment 80: the definition I gave is the one given in the in Task Managers Help, but looking at it it is incomplete. Task Manager has been notorious for such things and I should have looked elsewhere for the definition. VM Size is actually the same as private bytes. "Private Bytes is the current number of bytes this process has allocated that cannot be shared with other processes". That's why VM Size can be less than Working Set. Re: Comment 82: Agreed, it does share DLL's and probably other things. However IE's process does use about 1/3 less virtual address space than Mozilla, which would include anything that is shared. Now virtual address space is tricky, as it doesn't necessarily equate to memory, and it depends a lot on how it's being used.

Is this related to bug 639 ?

I'm seeing this annoying bug also. Very sloppy. Among others, I'm using these apps: Autocad 2000 Corel Draw PaintShop Pro Macromedia Dreamweaver, Netscape 4.7+ win2000, PIII 512 megs ram I'm seeing the same 15-20 freeze when un-minimizing Moz RC1 after 15-20 minutes. This is NOT a Windows 2000's problem. People fall too easily for this excuse. When Moz is the ONLY program doing this, you CAN'T blame the OS. All of these other programs un-minimize almost instantaniously. Moz churns the hard drive so bad and long, that it's scary. Defragged system makes no difference. Moz is the problem here. This and the funky text wrapping bug (83378) are probably the two biggest black eyes on Mozilla and should be addressed before 1.0. It seems these bugs are the result of *not* coding for windows first (with 95% market share), then porting to the other, more obscure OS's, but rather coding for the obsure OS's, and then *trying* to get it to behave on windows. Regardless of the facts, that's the impression.

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

Come on guys! Isnt this obvious: it is the very apparent bugs in the Mozilla memory manager/garbage collector. Although reducing the working set (after minimize) to the minimum is the *right thing*, but I don't think that swapping out the life critical data (like UI parts) is the sane idea. I would rather prefer to keep all the skin stuff to be kept in memory. My (probably pretty dumb) question is: Is it possible to split the cache items to those which could be easily swapped out to disk cache (like current opened pages) and to those which should be stay in memory (like browser window skin data)? As a short-term solution I would rather check the impact of using the standard (not garbage collected) malloc() API just for allocating data for all the UI stuff, and would see the result.

One of the first problems in isolating the cause of this problem is to come up with a reproducible test case. Waiting around for 20 hours is not acceptable. So I wrote the following program which allocates and touches all of virtual memory, forcing all background programs to be swapped out. My machine has 512MB of virtual memory so that is how much memory my program touches (actually it touches about 10% less than that because the program crashed when it tried to touch all the memory). You might have to adjust this number for your particular machine. The way to use this is as follows. 1. Bring up an application and then minimize it 2. Run the program shown below 3. Maximize the minimized application and time how long it takes I tried this with Mozilla, Netscape 4, and IE. Mozilla took about 15 seconds whereas Netscape 4 and IE took about two seconds. ------------- #include <stdio.h> #include <stdlib.h> int main(int argc, char *argv[]) { char* memory; memory = (char*)malloc(500000000); // allocate all of memory int i, j, k; for (i=0; i<29; i++) { for (j=0; j<4096; j++) { for (k=0; k<4096; k++) { memory[16777216*i + 4096*j +k] = ' '; } } printf("%d.",i); } return 0; }

Correction to my last posting: the program crashed when it tried to touch all the memory The reason it crashed was because my math was wrong. I allocated 5,000,000 bytes and then tried to touch memory beyond that. If I wanted to touch all 512MB in my machine I should have used a larger allocation. Furthermore, even though my machine has 512MB, I noticed that page swapping started to occur when I got to about 90% of that value (after the 27th time around the outer loop the print statements came out significantly slower). Obviously not all of the 512MB is available to my application.

I created this a while back to play around in stress testing memory. It's a Windows only executable, though. You can allocate blocks of memory, and then have it touch all that memory on demand. They used to have something like this in the Windows resource kit or SDK, but I couldn't find it. It was interesting as it didn't behave exactly like I thought it would. On allocation the working set climbs but then falls and then expands and shrinks several times. It does easily produce the behavior in Mozilla this bug describes. Also it's interesting to have two instances of this app running and battling each other. Also, I see two lags. One is when the window is first brought up. The second is when you go do something non-trivial (view another page, new window, etc.) and looks like GC kicks in.

I just experimented with Bradley's memhog program, and it behaves essentially the same as the one I posted above. I just want to clarify what I think is some confusion in the postings above. There are several different time points: 1. Native window outline and blue title bar appear (native win32 code) 2. Mozilla's chrome area appears (XML code) 3. Website content area appears (HTML code) 4. Menu buttons become responsive (C++, javascript code) Several of the comments refer to 1 occuring very quickly and then a long delay before 2 and 3 occur (bug description, comment 27, comment 40). Comment 36 on the other hand confused me since I thought it was saying that 1 and 2 occur quickly and then a long delay before 3. On re-reading that comment, I realize it was ambiguous. I'm posting this just so others don't get confused. What I personally am seeing (and what I believe the others are saying as well) is that 1 occurs quickly, long delay, then 2 and 3 occur (sometimes a noticable but small delay between them) and then another long delay before 4 occurs.

re: http://bugzilla.mozilla.org/show_bug.cgi?id=76831#c91, your sequence is exactly what i'm experiencing as well.

In response to #91, I would say that you cannot give a single 'the delay is here' type reply. I have seen delays at different points. For me, the delay is more typically when trying to browser again rather than just displaying the current window/contents when flipping back to the process. But, after not using it for a longer time, the delay is as you say. I guess the answer is really 'it depends what windows has swapped out'.

Here are some numbers that dp and I obtained by instrumenting a trunk build from May 24. We performed the following experiment: 1. Bring up browser 2. minimize window 3. run the memory-touching program of comment 88 4. maximize the window Durint the maximize phase, there is a dispatch of a SYSCOMMAND message (code 112 that was taking all the time (about 12 seconds). So we instrumented to a finer granularity to see what was happening during the SYSCOMMAND. The results were as follows: > Actions that occurs when a SYSCOMMAND (112) message is received. This > was obtained by instrumenting nsWindow::ProcessMessage. The curly > braces have been added to show where nesting occurs. Specifically they > are used as follows: > > {a a} around call to OnResize(rect) in WM_WINDOWPOSCHANGED > {1 1} around first call to DispatchFocus in WM_SETFOCUS > {2 2} around second call to DispatchFocus in WM_SETFOCUS > > D:s(112) <<< start of dispatching of SYSCOMMAND (112) > -WM_SYSCOMMAND 15MS > -WM_QUERYOPEN 1MS > -WM_GETTEXT 1MS > -WM_WINDOWPOSCHANGING 28MS > -WM_GETMINMAXINFO 1MS > -WM_NCCALCSIZE 1MS > -WM_NCPAINT 1MS > -WM_GETTEXT 0MS > -WM_ERASEBKGND 8MS > -WM_WINDOWPOSCHANGED {a > -WM_WINDOWPOSCHANGING 1MS > -WM_NCCALCSIZE 1MS > -WM_WINDOWPOSCHANGED {a > -WM_WINDOWPOSCHANGING 10MS > -WM_WINDOWPOSCHANGING 1MS > a} > 1349MS < > a} 1485MS > -WM_MOVE 0MS > -WM_SIZE 0MS > -WM_SETFOCUS {1 >< 1}{2 > -WM_WINDOWPOSCHANGING 1MS > -WM_CHILDACTIVATE 1MS > -WM_WINDOWPOSCHANGING 1MS >< > -WM_WINDOWPOSCHANGING 1MS > -WM_CHILDACTIVATE 1MS > -WM_WINDOWPOSCHANGING 1MS > -WM_KILLFOCUS 545MS > -WM_SETFOCUS {1 ><>< 1}8387MS <<< here's the offender > 2}10043MS > -WM_ACTIVATE 1MS > -WM_KILLFOCUS 2MS > -WM_SETFOCUS {1 > -WM_WINDOWPOSCHANGING 1MS > -WM_CHILDACTIVATE 1MS > -WM_WINDOWPOSCHANGING 1MS > -WM_KILLFOCUS 1MS > -WM_SETFOCUS {1 1}{2 > -WM_WINDOWPOSCHANGING 1MS > -WM_CHILDACTIVATE 1MS > -WM_WINDOWPOSCHANGING 1MS > 2}41MS > 1}218MS > d : 12335ms <<< end of dispatching of 112, time taken is 12.3 secs Note that the bulk of the time is spent in the WM_SETFOCUS case in the nsWindow::ProcessMessage method of nsWindow.cpp. This is occuring in a nested call to SETFOCUS, and the bulk of the time is spent of the following call in the nested instance: result = DispatchFocus(NS_GOTFOCUS, isMozWindowTakingFocus);

The above results were with a debug build. To better zero in on the problem, I decided to try the same experiment with an optimized build. This time the delay was less (as was to be expected) -- about six seconds. Unfortunately the delay was not as reproducible as with the debug build. That is, simply running the memory-touching program did not get back to the state of getting the six-second delay again. I occasionally got the delay, but for the most part the window came up almost instantaneously. Exiting and reentering the browser didn't help either. This makes it very hard to localize on the problem.

OK, I can reproducibly get the delay with the optimized build if I reboot the machine after each test. Makes it very cumbersome to run repeated tests of course. Here are the timing numbers for the optimized build. Slightly faster than for the debug build, but the offending call is in the same place. D:s(112) -WM_SYSCOMMAND 14MS -WM_QUERYOPEN 1MS -WM_GETTEXT 1MS -WM_WINDOWPOSCHANGING 2MS -WM_GETMINMAXINFO 1MS -WM_NCCALCSIZE 1MS -WM_NCPAINT 1MS -WM_GETTEXT 1MS -WM_ERASEBKGND 17MS -WM_WINDOWPOSCHANGED {a -WM_WINDOWPOSCHANGING 2MS -WM_NCCALCSIZE 1MS -WM_WINDOWPOSCHANGED {a -WM_WINDOWPOSCHANGING 2MS -WM_WINDOWPOSCHANGING 2MS a} 842MS a} 982MS -WM_MOVE 1MS -WM_SIZE 1MS -WM_SETFOCUS {1 1}{2 -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_KILLFOCUS 349MS -WM_SETFOCUS {1 1}4800MS <<< big offender 2}5740MS -WM_ACTIVATE 1MS -WM_KILLFOCUS 1MS -WM_SETFOCUS {1 -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_KILLFOCUS 1MS -WM_SETFOCUS {1 1}{2 -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 2MS -WM_WINDOWPOSCHANGING 2MS 2}10MS 1}264MS d : 7391ms

cc'ing danm and bryner since I had already discussed these timing numbers with them in private e-mail and they had some comments on it.

Note that the maximum amount of time on an optimized build is only 7 seconds, and that time occurs only on the first maximize following a reboot. All other maximizes are almost instanteous. I'm running on a 450MHz machine. So this doesn't appear to be a problem. Is any still seeing really long delays on an optimized build? If not, this bug might be a non-issue.

Mail & News Window and one browser with three tabs in it, both minimized: Memory usage: 4 500K VM size: 21 588K Maximize time without any heavy memory usage program: instant (0,5sec) Now, i launch Tribes2 (good online game) and play it for a while. After exiting mozilla memory usage is about: Mem: 8000k VM: 21552k But launch time is now ~18,7 seconds (finished swapping, and browser is usable), title bar appears in ~2 seconds. With some even more memory hungry programs, 18 sec is fast, i have seen it go near 40sec. So, how do i get that to your heads that it is an *issue* and it is not because of fragmented HD. Same effect is avery PC where i have tried it, mostly on win XP but also in NT 4.0 (serv.pack 6). Athlon 600mhz 258MB ram WinXP & WinME Duron 800mhz 516MB ram WinXP Athlon TB 1000mhz 256MB ram WinXP Celeron 300mhz(?) 211mb ram NT 4.0 (serv.pack 6)

For comparison sake, here is the timing for the case in which the window maximizes nearly instantaneously. D:s(112)-WM_SYSCOMMAND 1MS -WM_QUERYOPEN 1MS -WM_GETTEXT 1MS -WM_WINDOWPOSCHANGING 3MS -WM_GETMINMAXINFO 1MS -WM_NCCALCSIZE 1MS -WM_NCPAINT 1MS -WM_GETTEXT 1MS -WM_ERASEBKGND 1MS -WM_WINDOWPOSCHANGED {a -WM_WINDOWPOSCHANGING 2MS -WM_NCCALCSIZE 1MS -WM_WINDOWPOSCHANGED {a -WM_WINDOWPOSCHANGING 2MS -WM_WINDOWPOSCHANGING 2MS a} 9MS a} 18MS -WM_MOVE 1MS -WM_SIZE 1MS -WM_SETFOCUS {1 1}{2 -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_KILLFOCUS 2MS -WM_SETFOCUS {1 1}16MS 2}38MS -WM_ACTIVATE 1MS -WM_KILLFOCUS 1MS -WM_SETFOCUS {1 -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_KILLFOCUS 1MS -WM_SETFOCUS {1 1}{2 -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS 2}10MS 1}26MS d : 385ms

Just in case there was doubt in anyones mind as to where in the SETFOCUS code the time is being spent, I've instrumented further to show that it is in the calls to DispatchFocus. In the following data, the number following }1 shows the time spent in the first call to DispatchFocus, and followig }2 shows the time in the second call to DispatchFocus. D:s(112)-WM_SYSCOMMAND 2MS -WM_QUERYOPEN 1MS -WM_GETTEXT 1MS -WM_WINDOWPOSCHANGING 2MS -WM_GETMINMAXINFO 1MS -WM_NCCALCSIZE 1MS -WM_NCPAINT 1MS -WM_GETTEXT 1MS -WM_ERASEBKGND 2MS -WM_WINDOWPOSCHANGED {a -WM_WINDOWPOSCHANGING 1MS -WM_NCCALCSIZE 1MS -WM_WINDOWPOSCHANGED {a -WM_WINDOWPOSCHANGING 1MS -WM_WINDOWPOSCHANGING 2MS a} 813MS a} 883MS -WM_MOVE 1MS -WM_SIZE 1MS -WM_SETFOCUS {1 1}108 {2 -WM_WINDOWPOSCHANGING 1MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_KILLFOCUS 383MS -WM_SETFOCUS {1 1}3974 3976MS <<< the offender 2}4894 5004MS -WM_ACTIVATE 1MS -WM_KILLFOCUS 1MS -WM_SETFOCUS {1 -WM_WINDOWPOSCHANGING 1MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_KILLFOCUS 1MS -WM_SETFOCUS {1 1}0 {2 -WM_WINDOWPOSCHANGING 1MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS 2}9 11MS 1}434 436MS d : 6646ms ===================== Here's the code to SetFocus with the two calls to DispatchFocus clearly shown: if(!gIsDestroyingAny) { // BEFORE FIRST CALL, {1 IS PRINTED OUT HERE result = DispatchFocus(NS_GOTFOCUS, isMozWindowTakingFocus); // AFTER FIRST CALL, }1 IS PRINTED OUT HERE if(gJustGotActivate) { gJustGotActivate = PR_FALSE; // BEFORE SECOND CALL, {2 IS PRINTED OUT HERE result = DispatchFocus(NS_ACTIVATE, isMozWindowTakingFocus); // AFTER SECOND CALL, }2 IS PRINTED OUT HERE } ... }

I ran Quantify on this and it seems that we're spending most of the time from DispatchFocus inside nsXULCommandDispatcher::UpdateCommands, executing 2 js event listeners. What's interesting to note here is that commands are being updated because the focus controller is not suppressed. However, on Linux, the focus controller is suppressed, so we don't do UpdateCommands. saari, danm, or anyone -- should the focus controller be suppressed here so that we don't update commands? I'm not familiar with the event ordering on a window restore, but perhaps something is causing us to unsuppress early.

Thanks Brian. Can someone tell me what the call to result = DispatchFocus(NS_GOTFOCUS, isMozWindowTakingFocus); in SETFOCUS does? Since this is the offender, and the large amount of time fir this call occurs only when the SETFOCUS code is executed with gJustGotActivate false, I experimented and put the the above line inside the if(gJustGotActivate) statement. That reduced the total time significantly. But without understanding what this call is doing, I don't know what dire consequences moving this line of code would have.

That line dispatches a NS_GOTFOCUS event, which causes onfocus handlers to fire and our internal focus state to get updated. The "activate" event is fired when a toplevel window receives focus that did not previously have focus. So, if I remember correctly, the entire sequence goes something like this: - receive WM_ACTIVATE - receive WM_SETFOCUS on the toplevel window (WebShellWindow) - fire NS_GOTFOCUS on the WebShellWindow, which suppresses the focus controller - fire NS_ACTIVATE, which restores focus memory. This will cause us to: - focus the widget that receives focus from focus memory, triggering another NS_GOTFOCUS event. - Unsuppress the focus controller So, in theory, the focus controller remains suppressed the entire time, so I'm a bit mystified as to why we're updating commands.

Steve, right after restore before we got the SYSCOMMAND did we get a few (order of 5) activates and deactivates ? Anyway, my general feeling was we are doing way more than what we need to for min, restore.

Yes. After clicking on the icon on the status bar to maximize the window, we got the following activity prior to the SYSCOMMAND. -WM_WINDOWPOSCHANGING 78MS -WM_WINDOWPOSCHANGED 2MS -WM_ACTIVATEAPP 1MS -WM_ACTIVATEAPP 1MS -WM_ACTIVATEAPP 1MS -WM_ACTIVATEAPP 1MS -WM_ACTIVATEAPP 1MS -WM_ACTIVATEAPP 1MS -WM_NCACTIVATE 1MS -WM_GETTEXT 3MS -WM_ACTIVATE 1MS D:a(c0ac)d : 1ms

I'll take this. I'm testing a patch that should help this quite a bit.

Ok, explanation and patch forthcoming. When the app is minimized on win32, we actually null out the focused window on the focus controller. This causes its own set of problems which are covered in bug 95704. It's not clear whether the patch in that bug will actually fix this issue though. Anyway, the order of the null checks in nsWebShellWindow::HandleEvent means that we don't suppress the focus controller if the there is no saved focused window. That causes us to do a _lot_ more work than we need to, including a deactivate and updating commands twice. My patch simply causes us to suppress focus whether there's a focused window on the FC or not. It will be unsupressed when we get an NS_ACTIVATE event following the NS_GOTFOCUS. In my test, it made us about 3x faster at restoring the window after memory had been exhausted. So, this probably needs tested on multiple platforms, especially with cases of minimizing and restoring, activating/deactivating, and changing focus within a window.

I applied brian's patch and have obtained some very strange results. The time reported by the printf's in my program (see below) is now indicating 2.566 seconds which is a definite improvement over the what we had before which was about 7 seconds. That's the good news. The bad news is that my stopwatch time didn't agree at all. It indicated about 9 seconds. Previously my stopwatch time was in the same ballpark as the time reported on the printf. I tried this three times and got the same sort of result each time. I'm hard-pressed to explain how the stopwatch time and the printf time could differ by so much. Furthermore, in viewing the printf's as they came by, I saw a very long delay after the first -WM_NCCALCSIZE occurred. And of course that delay is not reflected in any of the times reported by the printfs. Another change is that now there is are two distinct delays in bringing up the window. One is after the window frame appears, as was the case before. But a second one is occuring after the browser chrome is displayed but before the browser content window is filled in. That second delay was not as pronounced before. D:s(112)-WM_SYSCOMMAND 46MS -WM_QUERYOPEN 1MS -WM_GETTEXT 1MS -WM_WINDOWPOSCHANGING 5MS -WM_GETMINMAXINFO 17MS -WM_NCCALCSIZE 2MS -WM_NCPAINT 1MS -WM_GETTEXT 0MS -WM_ERASEBKGND 8MS -WM_WINDOWPOSCHANGED {a -WM_WINDOWPOSCHANGING 1MS -WM_NCCALCSIZE 1MS -WM_WINDOWPOSCHANGED {a -WM_WINDOWPOSCHANGING 1MS -WM_WINDOWPOSCHANGING 1MS a} 768MS a} 894MS -WM_MOVE 0MS -WM_SIZE 0MS -WM_SETFOCUS {1 1}133 {2 -WM_WINDOWPOSCHANGING 1MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 1MS -WM_WINDOWPOSCHANGING 1MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 1MS -WM_KILLFOCUS 315MS -WM_SETFOCUS {1 1}98 99MS 2}1063 1198MS -WM_ACTIVATE 0MS -WM_KILLFOCUS 1MS -WM_SETFOCUS {1 1}0 {2 -WM_WINDOWPOSCHANGING 1MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 14MS -WM_WINDOWPOSCHANGING 1MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 1MS -WM_KILLFOCUS 1MS -WM_SETFOCUS {1 1}0 1MS 2}31 32MS d : 2566ms

Ok, let me reprofile this with my patch applied and see if anything new shows up.

Here's some more information. The reason that my printf statements no longer show the bulk of the delay is because significant delay is now occuring outside the regions that I was looking at. Specifically, the posts that I've included above are for the timing within the dispatch of a system command 112. But if I look further down in my output, I now see a long delay (which I don't think ws there before) in a WM_PAINT following the dispatching of the 112. In reading the output below, note that "D" means the beginning of a dispatch and "d" is the end of the dispatch. The number appearing after the "d" is the total time for that dispatch. D:s(112) -WM_SYSCOMMAND 19MS -WM_QUERYOPEN 1MS -WM_GETTEXT 1MS -WM_WINDOWPOSCHANGING 2MS -WM_GETMINMAXINFO 1MS -WM_NCCALCSIZE 1MS -WM_NCPAINT 1MS -WM_GETTEXT 1MS -WM_ERASEBKGND 2MS -WM_WINDOWPOSCHANGED {a -WM_WINDOWPOSCHANGING 2MS -WM_NCCALCSIZE 1MS -WM_WINDOWPOSCHANGED {a -WM_WINDOWPOSCHANGING 2MS -WM_WINDOWPOSCHANGING 2MS a} 620MS a} 717MS -WM_MOVE 1MS -WM_SIZE 1MS -WM_SETFOCUS {1 1}163 {2 -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_KILLFOCUS 221MS -WM_SETFOCUS {1 1}112 114MS 2}793 958MS -WM_ACTIVATE 1MS -WM_KILLFOCUS 1MS -WM_SETFOCUS {1 1}0 {2 -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_WINDOWPOSCHANGING 2MS -WM_CHILDACTIVATE 1MS -WM_WINDOWPOSCHANGING 2MS -WM_KILLFOCUS 1MS -WM_SETFOCUS {1 1}0 2MS 2}42 44MS d : 2086ms D:a(c130)d : 1ms D:s(f) -WM_PAINT 23MS d : 27ms D:s(f) -WM_PAINT -WM_ERASEBKGND 1MS 1716MS d : 1721ms D:a(c130)d : 1ms D:s(f) -WM_PAINT -WM_NCPAINT 1MS -WM_ERASEBKGND 1MS 44MS d : 49ms D:s(f) -WM_PAINT -WM_NCPAINT 1MS 5MS d : 10ms D:s(f) -WM_PAINT -WM_NCPAINT 1MS 5MS d : 10ms D:s(f) -WM_PAINT -WM_NCPAINT 1MS -WM_ERASEBKGND 1MS 240MS d : 245ms D:s(f) -WM_PAINT -WM_NCPAINT 1MS -WM_ERASEBKGND 1MS 626MS d : 630ms

Can anyone who is experiencing this problem regularly try applying this patch and see if it helps at all? Unfortuantely, the profile after applying the patch simply shows a lot of time spent painting, which is exactly what is expected. It simply takes awhile because of the sheer quantity of code that we have to bring in from swap to repaint the window.

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

I regularly have this problem at work and will give the patch a try tomorrow.

Tim, had a chance to try the patch yet?

Bleh, Unfortunately, I found out today I did not have all the MSVC components I needed to build mozilla(though I can build abiword just fine). I'm not sure how soon I'll be able to reinstall MSVC to get what I'm missing(it was an ATL header file, I'm suprised not to have it). Can anyone place a patched build somewhere I could download? I would be more than happy to test it.

I've posted an experimental 1.0 branch build with this patch at: ftp://ftp.mozilla.org/pub/mozilla/nightly/experimental/bug-76831/mozilla-win32.zip (For anyone reading bugmail vigilantly, it may take 15 minutes or so from now for the build to appear on the server).

Ok, i'll try it after work, later today. Any chance getting this to 1.01?

My initial feeling is that the patch does improve the restore time I'll try to get some hard numbers later. Neither of the memory hog apps seemed to work for me so I wrote my own. One thing I notice is that a restore after the manual memory hogging does not take as long overall as a restore from when mozilla has been minimized for half a day. BTW this is on a Windows XP machine w/ 128 MB of RAM and I never have this problem on my XP machine at home which has 512 MB of RAM. (I know, that's probably obvious) Also I emailed the author of comment #19 since he is not on the CC list.

Thanks for the email, Tim. I have added myself to the cc list now. This bug has certainly generated some interest since 1.0! I thought it might. For the record, my current Windows system is a P4 1.6Ghz w/ 128MB RAM running W2K Sp2. Mozilla 1.0 still takes about 25 seconds to wake up after being paged out. Unfortunately, I cannot seem to download the patched binary. Attempts to connect to ftp.mozilla.org give me connection closed by remote host. Can you email the binary to me? Otherwise, I'll try to connect again later.

Try this link location: http://komodo.mozilla.org/pub/mozilla/nightly/experimental/bug-76831/mozilla-win32.zip

If this patch helps, we need to know fairly soon if it is going to make MachV. If not, I'm afraid this will need to be pushed out until we can figure out some way to require less code to be swapped in in order to paint the window.

Well, I've been trying out the patch. Preliminary tests do show that it greatly speeds up the wake up time for Mozilla. However, every time I try to get into Mail now, I get a c0000005 access violation error in mozilla.exe. I even tried creating a new profile, but same problem. Can anyone else confirm this?

I'm not seeing that problem on my machine. What is your mail configuration? Does it crash as soon as the mail window comes up, or when you try to log in?

I have the mail crash problem as well with the experimental binary. As soon as I click the envelope -> Boom. In fact, 1.1 alpha's mail does not work properly with me either, so I had gone back to 1.0.

Okay. FWIW, I left experimental build running with so-called quickstart enabled for half a day while I was playing games etc. Then I activated it and it came up in about 5-10 seconds, instead of the 30-45sec it took before. Big improvement, yes. Still room for more. For whatever reason mailnews does not croak on me anymore. No idea why.

Although I have not had a chance to perform a "stopwatch-test" I can definitly say the problem has not been as bad since I've been running the patched version. It went from "major nuisance" to "minor annoyance" on my system at work.

Let's not make subjective guesses here. It's very easy to get an actual number and compare it with and without the patch. First of all, forget about turbo. It has nothing to do with this bug. What you want to do is start up the browser normally (no turbo running) and then minimize the window. Next you need to play around with memory hogs a little (see next paragraph). Then you maximize the window and use a stopwatch to time how long it takes for the page to appear. Also you might want to keep timing to see how long until you can get a menu to drop down (although that's a little harder to time). The hard part is the memory hogs. I've found neither my version (comment 88) or bradley's (comment 90) are very repeatable. That is, they will always work the first time, but they might have no effect after that. And you'll know if it doesn't work because the window will appear instantly when you go to maximize it. So, in the worst case, reboot your machine after each test. But I found it's usually not necessary to do a reboot -- bringing up a few heavy programs and then closing them (N4 for example) usually suffice. I did exactly as described above (see comment 110) and observed an increase in stopwatch time for the window to be maximized. Please try the same test and let us know whether or not your observations agree with mine. Thanks.

Not everyone has a C-compiler installed. I have the custom build, I can test it against the nightly build with same date. It breaks my mail, so it's kinda inconvenient for any prolonged testing..

I spent half'n'hour playing with the memhog. It's rather misleading to have it as ".cgi", since it's really a zip-file. In any case, what you have to do is to try'n'hog a little bit less than your physical ram and keep of touching the allocated block. You can monitor it with the task manager, after a few cycles memhog will have everything available. On my 256MB box, you can allocate 225x1000000 .. 230x1000000 will result in a much smaller ram footprint as windows will swap hog right out. Ok, the result: Inconclusive. I had ~10 second delay coming up to an active menu with both patched and nonpatched version. This was after making sure memhog had grabbed all available ram and freeing it afterwards. The REAL problem for me is that when I use(d) quikstart, starting mozilla would take very, very, very, very, very long time to start. Think 1 minute and up. Getting rid of quikstart got me back to about 10 seconds. Quikstart equals having mozilla minimized all day, no? The difference in the synthetic test and memhogging is that EDA tools really do put the boot in to get their RAM, unlike our piglet.

On the trunk, saari's fix for bug 82534 should make this patch irrelevant.

Pushing this out. I don't think we're going to get anywhere with this soon, and I don't have time for it right now.

I get this real bad. My computer at work is quite slow (PII) and I always have alot of windows open at once and change between them often. I find this quite a sudden change from Moz being able to return from minimised instantly at one point in time, and taking 30 seconds (and then being slow and unresponsive for 30 seconds more) Does anyone have a build with some timing code in that I can play with? I'm not familiar wuth the code and I don't think I'll get the time to make the changes myself, but I'm quite keen to see this fixed so that I can use Mozilla again. If someone can give me a build containing the stats you already have I'm sure I have a good chance of finding out more about it

It seems to me that 1.1 beta suffers from this problem more seriously than previous build(s). OTOH, this porblem is much more severe on the workstation I have at work than with my home PC, even if the former is quite a bit more powerful and they both run W2k with SP3 applied. I just now had to wait for 40 seconds for mozilla come up and become responsive after being minimized. System resources show approximately 64MB of unallocated physical RAM and no other apps are open. However, a while back I was working with word etc, so it is quite possible mozilla was swapped out. In any case, I think it's completely unreasonable to tag 30+ second reactivation time as "ok" since starting mozilla from scratch takes a lot less time. I usually leave the mailnews app open to get a notification of any new mail and the response time is as bad either just opening a the mailnews or firing up browser window. If I actually get an email notification, mozilla comes up just like that when I click on the envelope. Apparently it does whatever it does prior to giving me the email notification.

Yuck! Is the missing linewrap a bug with bugzilla or mozilla?

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

I'm glad to find this bug and I'm surprised to it still drag on for almnost 1 1/2 years. I use Win2000 and I didn't like this bug becuase it slow down everything. It seem to be improving as it approach Moz 1.0 but didn't do so well as it approach Moz 1.1 beta. For the sake of everything, here's this wild thought. Make the browser appearance show up first fast and quick. Then make the functioning of the features like menu bar, buttons, history list, etc. to work 2nd. Remember it only take human being a second or two to response. Then somehow bring up the most recent to the front while still bringing up everything at the bottom of the pile back up and running. Wouldn't it make sense that way?? P.S. The OS should not be set to WinNT since it also affect most of the Windows. Should it be change to ALL??

'All' implies all OSes, not just Windows. Its set as 'Windows NT' because that's the earliest Windows version it affects. I suppose it could be set to 'Windows 95', but the point is rather moot.

Cool! How about a new creation in the OS scrollbar. Let's say "Windows (ALL)". That way, it represent about all Windows. Yes, We know that Win95 and Win98 use similar architecture. The same for WinNT and Win2000. WinXP is the combination of (Win95 & Win98) and (WinNT & Win2000). It doesn't meant they all share the same architecture type. So, a penny for my thought! It would be cool to see that "Windows (All)" in the OS scrollbar as a new addition.

Scott: This isn't really the place to request a change in the OS options ;). However, if you would like to do so, you can file a new bug in the product "mozilla.org" under one of the "Bugzilla ..." components.

i'll second the notion that this "seems" worse recently that it had been. it felt to me like the trend was getting better, and even up to the 20020814 1.1 nightly build, i think, was better that it had been a few months ago. i had actually quit conciously noticing it. however, 20020818 seems significantly worse than all those other recent builds. i.e. it's back in-my-face obvious again :-(

I did a little bit of a experiment. See comment #134, I use Pentium II with 128 MB RAM. The way Virtual Memory work, it worked pretty well the way it is suppose to be. There is no sign of Resource Hog. See comment #113, Brian Ryner stand correct about the time being spend on painting the whole screen. The frame outline and the blue bar at the very top showed up instantly except the painting of the rest. I use the MS-Outlook and Visual SlickEdit. I played around in clicking on those in the task bar. I noticed the response time of the painting is a bit slow the first time. Once fully painted, I minimize it and quickly bring it back up. The painting did not seem to be redrawn and it act as if it was already there. Did this experiment on a couple of other applications and got the same result. So, I test it on Mozilla and noticed a very noticeable difference with the repeating action of minimizing and un-minimizing Mozilla with the click of a mouse in the taskbar. The problem lie with the draw/paint starting time. It just did nothing for almost 1 second then immediately start drawing/painting. You can tell when you see the window bar at the very top (above the menu selection), it already shown up and the rest below of it isn't. You will need a superman's eye to see the speeding bullet, so you'll have to look at it carefully. All you need to do is to see the window bar and the color below it at the same time to see it. Do the clicking on the Mozilla in the taskbar to minimize it and un-minimize it repeatly, let your recognization of the images and shape to sink in and you'll see what I meant. This will be a very useful tool in debugging the delay in draw/paint starting time, allowing you write the patch almost on the fly. No need to wait 30 minutes for Mozilla to become idle while it is already minimized. I urgently suggest that you use this method because timing is more efficient. Just don't bother to stare at the effect for 10 minutes or your eye will popped out! All you need to do is to use common sense and find out why did the draw/paint starting time stayed idle for almost a second (with the minimize & vice versa stimulately) before it start painting. I have the confident that once this problem is fixed then you'll find a faster response time when un-minimizing Mozilla after 30 minutes of idle time and find the draw/paint starting time to be a little bit quicker. Worry about the draw/paint completion time later. Hopefully, you all will adopt this method for starter. Like why did it wait to start painting? Do you agree with that? What about you, Brian Ryner?

When this happens, Mozilla is slower at coming back up than it is when it is first launched. The big memory footprint probably has a lot to do with this. So a thought for a test build is to clear the memory cache whenever you minimize.

I'm adding a comment because I can't believe this bug isn't a huge priority. With 3.4% (and shrinking) total user base - see article snippet from Salon, below - how can releases of this product continue to ship with bugs that render Mozilla unusable? I would love to use any reasonable product in place of Microsoft software, but I can't wait a minute or more for Mozilla to respond each time I need to access the web. One last drink for old times. I'm sadly switching back to IE. Sept. 10, 2002 | On Aug. 28, WebSideStory, a firm that keeps statistics on the software that people use online, released some numbers confirming what most Web surfers who think about such things already know: Almost nobody uses the Netscape Navigator Web browser. WebSideStory reported that Netscape, the company many people credit with sparking the Internet revolution, is now forlorn in the world it helped create, claiming only 3.4 percent of the world's Web users. That's a stunning decline from just a year ago, when Netscape had a 13 percent share -- and especially from the company's heights of the mid-1990s, when virtually everyone used its browser. But now, 96 percent of the people online use Microsoft's Internet Explorer, and it's likely that Netscape will lose even more ground in the future, according to WebSideStory. "The browser war," said one of the firm's executives in its press release, "is in fact a massacre."

Since I switched to Mozilla 1.1 and activated QuickLaunch, the problem seems to be minimized. Does it only apppear with no QuickLaunch option used, or is it resolved in Mozzilla 1.1?

Do not underestimate this problem, it's not have been voted 27 times for nothing. This is very annoying bug because it's totally unpredictable for those who actually uses their computer something else than browsing. This is very key may of my friends choosing between Mozilla and ...rival... browsers. For me, restoring browser takes 1-40 seconds, from taskbar or from systray and it's *really* making me nuts when trying to do something fast. Btw, its not about my HD is fragmented as some of you tried to point. There is patch already for this and i really hope that it will land to 1.2. Tested on: Duron 900, 256MB. WinME, WinXP, WinNT 4.0 sp6

If you're talking about the 6th of July patch, it's not quite a clear-cut solution. Coders talk about milliseconds, where the real problem is having to wait upwards of 30 seconds on a high-end box. I get hit with this one bad at work, where I use some big footprint apps daily. Simplest workaround is to never leave mozilla open, minimized or not. Interestingly, when I have forgotten mail open and I *know* it'll take forever to restore mozilla, trying to kill the process takes just as long. For what it's worth, I haven't paid attention to the problem lately, so 1.1 is not as bad as some builds. Maybe.

This bug used to drive me up the wall but since I re-installed W2k on a new hard drive the problem has gone away. The new hard drive is NOT phyiscally faster than the old one. This raises questions to me: - Is it just that more recent versions of mozilla are better (now using >1.1) - I had degragmented the old hard disk, but perhaps the swap drive or registry or something was still fragmented or something - Maybe it's just a windows thing - I've noticed an FDISK once a year really helps anyway - Maybe my tolerence level has gone up and I don't notice the odd delays now and then! I should mention that the problem hasn't completely gone away - occasionally there are still several second pauses on a reload, but not the 30 second ones I used to get.

From comment 146, the quick launch reserved some spaces in the RAM. It was design to make the Mozilla fire up more quickly when Moz isn't running. I'm not aware of this feature being used for minimizing and un-minizing, I don't think there is one for this.

Wow. Some people don't get that: 1) Bugzilla exists to help solve bugs, not bash programmers. 2) Whining is not going to get a bug fixed. 3) If you value speed of waking over security and features, by all means go ahead and return to IE. Personally, I solved this problem for myself rather nicely. I wiped w2k and installed Mandrake.

Can anyone confirm seeing this problem with 1.1 release? I used to have it real bad at work (w2k) with 0.9x-1.0. Now it seems to just have gone away.. I saw a mention in release notes that the quicklaunch now reloads mozilla when the last window has been closed. Sounds like a workaround, but if it works for now.

Nope, I still got this in 1.1. Just installed 1.2a so will report back in a few days if it's any better.

As stated before, this is a serious bug. Today I had a discussion about the prefered browser with two of my collegues. And although they would choose another browser over IE it wouldn't be Mozilla right now. The main reason is the huge swap-in delay Mozilla has in Windows (2000), if this is solved I'm sure I can convince one of them to switch and almost sure the other would switch too. [And actually I would be happy too :-)]

I doubt that anyone disagrees that resolving this issue is of importance to the long-term success of Mozilla. I have heard many anecdotes of sloth-like restores from a minimized state within my own organization and among friends. I even experience the issue periodically. While it has not significantly diminished my enjoyment in using Mozilla, it is high atop the lists of peoples' pet peeves; it seems especially so among those who would be less likely to use Bugzilla because they feel no particular need to help Mozilla become better than it is today. That said, I would agree with any of the programmers who have said that fixing this is not going to be easy. I am not sure if I share the optimism that asks, "is it fixed in the latest build?" Without knowing for certain, it sure seems that fixing this sort of thing would involve a significant undertaking. If that is true, then it won't be fixed without some follow-up fanfare. All I can add is to reiterate that low-memory is just an easy way to replicate the problem and not really the definitive cause. Every time I have experienced the issue, my machine was not in a low-memory situation. It's just that Windows 2000's super-aggressive paging algorithm decided to page out Mozilla merely because it was minimized, even though I may have 500Mb of memory free. Silly Windows. Another application that exhibits the same behavior--and is actually much worse about it--is the Eclipse development environment. That bad-boy takes its sweet time to restore from an overnight minimized state.

Nobody was ever fired for blaming microsoft. Even if W2k/XP memory management was dodgy, how come majority of apps can deal with it? Why is it much faster to fire up Mozilla instead of restoring it? Why is there no disk churning or other system slowdown when mozilla takes forever to come up? My personal quess would be that a small wait somewhere in the code is getting called n times with right conditions. Could it be possible to produce a test build which would log breakdown of the time spent bringing up moz? With timestamps, maybe? That way whoever is hit with this problem this week could actually do something productive about it..

I see some people still don't read all of hte comments carefully and went on to post comments or jumping the gun. Here's a saying, "Don't count the chick before the egg hatch"! See Comment #19, Comment #96 and Comment #112. Comment #112 is as result of the patch from 6/6/02 but on comment #132, the bugfix make this patch irrevelant. Based on Comment #19 and from what everyone have been saying, the window frame showed up instantly but the paint redraw haven't fired up for a while. So, what make the WM_ERASEBKGND, WM_PAINT, WM_NCPAINT taking it's time? Should be something we should look into.

Unfortunately, I'm wrapped up in other work and probably won't be able to look at this anytime soon. This bug should probably get a new owner. Anyone willing to step up?

FWIW I think we can conclude from all the memory stress testing that the problem is NOT a simple Win32 performance issue. At least I had mozilla coming up way way too fast after playing with the memhog applet. I made sure all the non-core physical memory was committed by memhog and restored mozilla window. Furthermore, I had the expected disk churning while restoring mozilla after hogging.

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

I just wanted to add an observation. If my rough judgment of time doesn't deceive me, Phoenix (0.3) seems to be even worse than Mozilla 1.1 (on my Win2K) - FWIW.

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

I think that it's related to mozilla working set being too high Maybe a MOZ_COVERAGE build coud help here MOZ_COVERAGE is supposed to minimize page faults by putting code used during a given test scenario (startup, maximizing, minimizing, etc...) in adjacent pages. This is a 2 pass process, first collect the data then make a final build with the collected data. I think that it could be usefull when Mozilla gets maximized after a long period of inactivity. Unfortunately I don't know if MOZ_COVERAGE is still available with new GNU make build system.

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

The bug is still present in Mozilla 1.2 under XP. About 20-30 seconds restore time, and this is the only application where the problem occurs. I watched CPU and memory usage on my Athlon 1800+ (256 MB) during the slow redraw, but they stay way low (no significant difference to normal idle operation), so this is not the reason for the bad performance.

Something that can really kill performance is two disk accesses at the same time. It's hard to believe that simply swapping could kill performance so much, but maybe it's something else, like trying to read from the cache at the same time as Mozilla is read in from the swap file. That could cause really bad I/O performance. It would be interesting if this is seen by anyone who has the swap file on a seperate disk (completely or at least seperate from the cache disk). I should try to see what's happening with sysinternal's filemon, but I have trouble reproducing it. The 'hang' only happens when I not expect it.

One interesting thing sicking and I (mostly sicking) ran into the other day is that when you unminimize the Mozilla window on Windows we actually reflow (as in, nsHTMLReflowState::Init gets called, which means that a reflow is happening somewhere). On Linux, unminimizing does not involve a reflow. Is this because on Windows unminimizing involves a resize operation and thus triggers a resize reflow?

When you minimize on Windows you'll get a WM_MOVE and then a WM_SIZE message sent to you. Is that what you are referring to?

iirc (sicking, correctly if I'm wrong) when we _minimize_ we don't reflow. When we _unminimize_ we reflow.... It may be worth seeing whether we can eliminate that reflow and if so how it affects this bug.

Re comment 166 - I have my swap file on a separate physical disk (on Win2K), and I still get this bug.

Yes, we didn't seem to reflow on minimize but on we do on restore. Maybe we have some code somewhere that suspends reflows/repaints when in minimized mode which is why only the unminimize causes a reflow. Either way it might be a good idea to try to not cause any reflows between the minimize and the unminimize so that on onminimize we only have to repaint.

as long as you leave the reflows in the queue and process them when you unmimimize, otherwise dynamic content can get unhappy

I don't know whether I can shed any sort of light on the issue (and after reading through most of the 170+ comments, I doubt that I can), however one of the things that I DID notice between my work computer and a coworkers: we have almost identical machines (Windows NT4 with SP6), same harddrives, same everything (he has a little bit less harddrive space left than I do), BUT I am using a built in video card (that uses shared memory), and he has a separate (some nVidia card) video card with it's own memory. I see the problem, he doesn't. I don't know if it's related to a onboard video card memory swapping competing with normal memory swapping or something. I ALSO see a problem (probably unrelated) when I click the minimize button. My whole terminal locks up for about 5-10 seconds (nothing works outside of mouse movement) after I click the minimize button. It's almost like the "window manager" is frozen (except for the mouse). If I have a Task Manager showing, it halts while the whole computer is 'frozen' then unhalts itself (which a super quick spike in CPU useage at the tail end of the halt that almost immediatly goes back to normal).

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

This is not a hang. It's a performance issue. I'm not sure that the "arch" keyword is appropriate, either.

Can anyone explain what the 'arch' is??? Short for architecture?? That's what it look like. The term 'performance' is the apppropriate term as long as it is not the term 'stability'.

I have noticed this more on my computer recently, with 1.1b happen quite swiftly I have installed Visual C++ and using lots of other resource heavy apps. Since then I've produced this problem regularly while VC++ etc are running. The specs of this machine are: 750 Duron, 128MB, Win2K SP2 recent install, Creative GeForce 4 MMX 440 video card. There is no improvment in performance over the orginal machine I reported this on. (333MHz Windows NT etc). It is possible I can find a set of steps to reproduce this

FWIW, this is worse in 1.2b than 1.1 .. With XP1700+ and 512MB.

st8 and Olli: Your builds are rather old. Please try a more recent build: http://ftp.mozilla.org/pub/mozilla/nightly/latest/ (as always, be sure to delete your old Mozilla directory before installing the new one)

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

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

as i point out in my dup Bug# 196055 comments... running Debug->Leak Detector->Dump Memory Leaks seems to restore normal functionality... wouldn't a simple solution be to just call this routine, or whatever garbage collector is preferred, every 5-10 min??? yea, it's an ugly hack, but if it works... for the record, this bug still exists in 1.3b (Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3b) Gecko/20030207)...

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

In bug 194959, which has been duped against this bug - it was pointed out that the problems only happened when using specific video card / drivers - Nvidia Geforce4 MX 420 (Driver 4.0.7.2). Performance problems ended using an earlier version of the Nvidia driver (3.0.8.4). The problems were also solved by going to www.nvidia.com and downloading their recommended latest drivers (as opposed to those endorsed by MicroSoft). Running with driver version 4.1.0.9 does not have any delay in maximising windows. If it s a true dup, perhaps updating video drivers would benefit others- although the behaviour in bug 194959 occured all the time - not just after long periods of inactivity.

I can see this problem with an Nvidia card and the latest drivers. I have always seen this problem with all versions of Mozilla since 0.6 something both with my old K6-2-300Mhz/ATI card and my newer AthlonXP1700+/Nvidia. That's the reason why I never leave Mozilla open during the night (PC is on 24h/24h), it can take up to a minute to "wake up" on the morning.

this is not limited to nvidia cards since i'm defenetly seing this and i don't have nvidia

Isn't it possible to analyze or debug the scripts' effect in the Mozilla's files and compare it to varieties of video cards to see if there is a pattern as to what cause the problem with the delay in unminimizing the browser window. It wouldn't hurt to give it a try because something might be there where we least expect it. I don't know where to start from there.

It seems to me that the video card issue is something else entirely, since it happens immediately instead of after long periods of inactivity, and this issue is seen with all video cards. I don't think that bug should actually be duped to this one.

since no one seems to have tracked down the source of this bad boy yet, it may be helpful to note that i cannot seem to reproduce the problem with only a single window open (ie: prob appears w/ multi tabs, not when all tabs are closed save one)... can anyone else confirm this?

I've seen this without any tabs whatsoever, too. (I never use tabs). Also, I believe that when this bug was filed, Mozilla had no tabs.

I too can reproduce this with no tabs.

Running a Norton Corporate AntiVirus scan with Mozilla minimized seems to be a repeatable way to cause the problem on my machine.

These comments apply to a Win2k machine with 392Meg of RAM Does Windows have some sort of memory allocation call that allows an application to specifiy it's degree of "unwillingness" to be swapped to disk when minimized? If I open a .PDF document in a tab and then minimize Mozilla, the Adobe Acrobat Plugin seems to stick around in RAM hanging onto 30Meg while Mozilla will shrink down to a 1.2Meg or so when minimized.

Then you'll get a bunch of other people complaining about how Mozilla slows down other applications when it's not in use.

Is there a middle ground here? Could the strategy change based on available physical memory?

c'mon people. What memory is paged out and what it not, is decided by the operating system kernel. The only way an app can affect that is by changing which parts of memory it "touches" (reads/writes), or by calling a memlock routing on whichever OS mozilla is running on (but in unix,you need root access for that, and that's not an option). This bug should depend on the bug for large memory footprint, and that's it.

Mozilla memory footprint is neglible in 512MB machine. And it sure should not take one minute/sixty+ seconds to fire things up after long time of not being accessed. No other app I have suffers from such slow restore time.

Using the latest Mozilla, Pheonix, and Thunderbird on WinXP, PIII 750 512 megs ram on a well defragged system. ALL of these programs have one heck of a time coming back from being minimized for several minutes. If you happen to be doing some video editing, they NEVER really come back. Much quicker to right- click the taskbar button, kill them and start over. This isn't getting better at all. By comparison, Opera 7+ comes through the same tests with flying colors. Note that Opera and Moz/Pheonix/Thunderbird all have about the same memory foot print. They all swap out to disk down to about 5 megs or so, and all use about the same mem foot print while running (17 to 20 megs). So it's NOT that they have a huge memory foot print. So, why has Opera figured out how to function on an NT class machine and Moz hasn't? I've got to say that this alone is keeping a lot of people from using Moz/Pheonix/Thunderbird as their main browser/mail. N7 is, of course, just as bad. I can expect this from Thunderbird, being new and all, but Pheonix/Firebird behaves just a badly as Mozilla 1.4a. My work has over 200 win2000 machines and will not use any of the Mozilla products because of this. The killer is, Moz is a great product otherwise.

I have seen from other bug reports that you cannot request a bug blocking if there is no patch(es) or if no one is currently working on it. Just letting you know...

Adding vote. And asking for a priority change to "Major".

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030326 There are reports from OSX, and now Linux requesting OS->ALL Re: Comment #5 bz, Is there anything we can do to get mozilla to use fewer files? (like the recent shared library colsolidation in mail/news) Does mozilla purge the rendered images from memory in chrome when they're not visable? Re: Comment #65 David Bradley Is this still true with the GC? Is there a bug filed about this issue? Hmm, it looks like bug 66381 from Comment #72 will help for this... I can confirm Comment #68 "Wakeup 4-10 times slower when another disk intensive app is running". For me, when I run a apt-get upgrade in the background, it does the same. Re: Comment #87 From Timur Safin Has anyone looked into this? Is there a bug for this? Confirming Comment #91 From Stephen P. Morse 2002-05-21 10:26 on Linux. re Comment #171 That depends on Bug 639

Stupid me... Sorry.

Maybe this is kind of like bug 120154?

I don't see how this has anything to do with GIF images, also, IIRC the processor usage isn't very high during the wait for a responsive mozilla (can someone double check on windows? I will check on Linux) Also, "stupid me" was reffering to that I got the depends/blcoks dependancies backwards...

In response to Comment #192, this doesn't seem to be the case when Norton is running. I have WinXP with 512 MB RAM with both Norton and Photoshop running. Left the machine on overnight and use Mozilla the next day, it just pop up in a second from the minimize state.

Congrats. You have now taken a bug for a somewhat specific windows-only problem and morphed it to a general bug for a cross-platform problem that is very elusive if present at all. It's now poised to get a bunch of clueless people saying it works for them on Linux and Mac. Wakeup when the disk is busy is NOT this bug. Wakeup when another app is sucking CPU is NOT this bug. This bug is about Mozilla, on Windows NT based OSes only (not any other OS, including Linux, Win9x, Solaris, MacOSX, BeOS, AmigaOS, OS/2) being slow to unminimize when there is absolutely no reason for it to be slow. The way to get mozilla to use fewer resource files is to drop all UI customizability and just hardcode it all into the binary. <shrug>. In any case, I strongly recommend you undo the last batch of changes; if Linux and OSX have similar problems, they are almost certainly caused by totally different underlying causes.

Boris is probably right. Garbage collection *can* make this worse (and is cross platform), but there are some windows specific parts that this bug should focus on. (read the traces that were posted in previous comments. So let's split off the other bugs reported here, there are at least two or three. Anyone care to help me find them? Also, my previous questions still stand... requesting OS->winNT

This is a patch that tries to do what I described in the newspost in n.p.m.performance today. It's NT/W2k/XP only so it should only be seen as a proof of concept patch and I don't even know if it proves anything. I would welcome any testing or feedback on it from anyone able to apply the patch. The idea is to use SetProcessWorkingSetSize when a window is restored after a minimize to tell the OS that the process once again needs lots of memory.

You can't simply say that this bug is caused by the OS reducing the working set. I did a quick test on Windows 2000 with Mozilla and IE. Opened both browsers, browsed a few web pages, then minimised both: IE6: VM size: 11 megs mem usage: 5 megs Mozilla: VM size: 11 megs mem usage: 2 megs IE6 took about 1 second to unminimise, whereas Mozilla took about 5 seconds. It looks like IE has a larger minimum working set size, and this is making it more responsive than Mozilla when unminimising after a period of inactivity. This bug may be been introduced by a "fix" for bug 108475: "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." The fix for bug 108475 involved adding the above function call to reduce the minimum working set size. I suspect that this has caused the slow startup problem, and we would be better leaving it to the operating system to determine working set size.

You can't simply say that this bug is caused by the OS reducing the working set. I did a quick test on Windows 2000 with Mozilla and IE. Opened both browsers, browsed a few web pages, then minimised both: IE6: VM size: 11 megs mem usage: 5 megs Mozilla: VM size: 11 megs mem usage: 2 megs IE6 took about 1 second to unminimise, whereas Mozilla took about 5 seconds. It looks like IE has a larger minimum working set size, and this is making it more responsive than Mozilla when unminimising after a period of inactivity. This bug may be been introduced by a "fix" for bug 108475: "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." The fix for bug 108475 involved adding the above function call to reduce the minimum working set size. I suspect that this has caused the slow startup problem, and we would be better leaving it to the operating system to determine working set size.

Comparing IE6 and Mozilla for this has its flaws. Realize that IE6 and Explorer share many things. Even when you minimize IE6 it may not get swapped out as much as Mozilla due to Explorer still actively running. So when you restore, IE6 has kind of a head start. Also to correct one statement. Setting the working set size to -1 doesn't swap the programs memory out of physical ram. It only marks the memory as available. If nothing uses that memory before the application needs it a transition fault occurs and the memory is reclaimed without having to reload it from the swap file. Ideally this should be extermely fast.

Actually, I've just done some more investigation, and it appears two calls to setProcessWorkingSetSize(-1,-1) have been removed, so unless there are any more in the code (I haven't done a search through the entire source), this doesn't appear to be the problem. Maybe there should be an option to actually increase the working set, which could be set in the preferences. The user would then be able to decide whether to give mozilla extra ram in order to increase performance. This would go some way to bringing Mozilla on a par with IE, which appears to be less prone to swapping out (presumably because it's half built into the OS).

"This bug may be been introduced by a "fix" for bug 108475" Interesting. This is bug 76831. It could not have been introduced, but could have been exacerbated by a fix for bug 108475. If increasing the working set size is easy, a patch could be posted, and interested users could give it a try.

Just another of my two cents. Moz 1.4rc1 is just as bad as ever with this minimize bug. I had about 10 tabs open and Minimized Moz overnight (though 1/2 hour produces about the same result). I took so long for all elements of Moz to become responsive again, it was unbelievable. Approx. 60 secs for the whole thing to back to life. Much quicker to shut Moz down and start over. This is going to be a big black eye for the whole project if Moz goes final with this bug still as bad as ever. AGAIN: WHY IS MOZ DOING THIS SO BAD, WHEN EVERY OTHER PROGRAM RESPONDS IN 1/4 OF THE TIME?! I'm talking large graphic editing programs, browsers, autocad, you name it. Pheonix, F-bird, or whatever it's name is seems no better. The kicker is, this is so very aggravating, but I still use Moz because it is such a great browser in every other way.... very frustrating. WinXP PIII 750 512 meg ram, defragged.

How about a debug build? One that would log time segments for every component to come up? That'd help zeroing in on the problem? There are lots of guys who have had the bug for years so plenty of people to submit results.. Personally I haven't had the problem bad for long time, but then again, I stopped using quick start feature a year ago since it aggravates the problem.

I'm not sure whether this is known to all: The problem is *not* limited to the case that Mozilla is unminimized - it seems to be a general performance problem after long periods of inactivity. Sometimes I leave Mozilla running *maximized* over night, and when I try to poll my E-mails next morning, it's very slow for about 20 seconds or so (Win XP, Athlon 1800+, 256 MB), even though it did not need to redraw the window in this case. Unminimizing just makes it even worse, probably because even more work needs to be done at the slow performance.

RE comment 216, I agree. Unminimizing makes this problem a bit worse but inactivity is all that is needed to make this manifest. After a long period of inactivity, the program is unresponsive for 15 seconds or so.

Problem is still present in Mozilla 1.4 final. Sigh ... I'm seriously thinking about switching to Opera or returning to Internet Expluargh ... :-( Wouldn't it be possible to insert some debug code into Mozilla that writes time stamps to a file (or maybe better to an array in RAM that can be read later) after each step it performs during the reactivation phase? Maybe that would help to find out which part of the procedure actually takes that long.

How about that debug build that logs times during come-up?

I'm not going to bother scanning the whole sordid bug listing (which started over 2 years ago, btw) to see if the points below have been mentioned yet, but the developers need to know three things: 1. this problem is not limited to Mozilla, it also affects Phoenix/Firebird 2. this problem is not related to Quicklaunch (since it happens on Firebird) 3. this problem is not *caused* by minimizing, though that probably exacerbates the problem. SUGGESTIONS - Rename this bug, e.g. "inactivity causes prolonged disk-swapping". Currently, it sounds more benign than it actually is! - Remove this bug's BLOCKER status for bug 108795 since I really don't think it's related to Quicklaunch - Fix this bug! P.S. I have this problem with Win2000 on a P3 system with 512MB of RAM. I don't even know why ANYTHING is swapped-out to disk?! I tried disabling my swap-file but other apps complained.

I have been upgrading to each release of Mozilla hoping that this problem would go away :( This is probably the only Mozilla drawback. However, otherwise Mozilla is such a great email and browser package that I am NOT going to switch !

Is it just me, or is this behaviour now also being exhibited by Mozilla Thunderbird 0.1?

I'm definitely see this occasionally with Thunderbird 0.1

as far as i can tell, it's exhibited by every app that uses Gecko.

I would greatly appreciate if the developer(s) working on this bug could post updates about his/their progress here from time to time. Otherwise we users might get the impression that nothing is done about it. It surprises me that a bug that probably keeps most people from using Mozilla on the world's most popular (though not best) operating system (XP) has still not been labeled as a blocker for upcoming releases (severity is still set to "normal"). Or is it just me and most XP users don't encounter this bug? Do you have statistics? By the way, I recommend to remove the "(minimized window)" from the bug title, since the problem is definitely not restricted to that, as several users have confirmed. Keep up the good work! Joerg

FWIW, I have never had the problem on my home machine (1024MB RAM), but do have it on my work machine (256MB RAM) with Firebird. The former has the swap file turned off, but the latter does not (set to the default 1.5 * amount of RAM). Both run WinXP. It seems like 512MB is around the switchover point based on previous comments with and without problems. If this is a working set issue, is this size somehow calculated based on the total amount of RAM?

I recently upgraded my XP PC from 256 to 512 MB (keeping the default swap file settings), but as far as I can see, that did not change anything - problem still present.

I'd be interesting to know what the value on Task Manager is in the Physical Memory (K) area by "Available" reads. Is this less than 6,000 k for the people seeing this problem?

OK, I checked on my system (Windows 2000, 384 Meg of memory) by starting various applications. With 116,340 K showing as "Available" in the task manager, I am starting to see this problem. (I used Thunderbird 0.1 to test.)

I'm not sure if this is relevant, but I haven't noticed this bug as much since I started avoiding "minimize". I was using the Windows meta key with "m" which minimizes all windows. This bug annoyed me so much, I started using <Windows>-D to "display desktop", which I suspect is different than minimizing all windows, even if it achieves a similar effect. I don't seem to encounter this bug as much this way. Maybe this might help determine what is going on. I'm testing with two systems: - WIN2K 600Mhz 512MB - WINXP 900Mhz 640MB 1.5GB swap on each. Max memory usage never peaks over approx. 280MB in Task Manager.

joerg: thank you for volunteering.

I checked the available physical memory under XP in two cases while the problem was present in Mozilla 1.4. It was around 200 MB in one case and around 300 MB in the other (some other apps were running as well). I have a total of 512 MB. So I don't believe this is a problem of too little physical RAM. Also, I didn't notice a significant change in the memory numbers while the problem disappeared (it generally seems to disappear gradually, not suddenly). The problem also doesn't eat up the CPU power.

Mostly likely what's occuring is that once Mozilla is minimized Windows begins taking the pages put in transition and using them for disk cache. I really think the two issues at the heart of the matter are the GC routine having to ouch many block of memory causing a large portion of the app to be paged in even when those objects may not be actively used. And then possibly the fragmentation of objects across pages. As GC occurs and/or objects are access they don't hit pages sequentially as they were stored, but at fairly random distances. This causes the retrieval to be even slower than just reading the same amount of data sequentially from the disk. This might explain why some people's system it's faster to just terminate the application and restart it. From your description, available memory being up, low CPU usage during restoration is the symptoms of paging. Was there a fair bit of file I/O while you had Mozilla minimized? See my comment 211 for an explanation of what's going on here.

Thanks, David - it looks like your paging theory is correct. I just minimized Mozilla at normal performance, then copied about 2 GB of files from one HD partition to another (took about 15 minutes), then restored Mozilla and indeed it was slow (though not as slow as in the worst cases). This would also explain why the problem seems to appear randomly and definitely not directly dependent on the time that has passed (sometimes it restores just fine after several hours of inactivity). If it depends on disk activity, then it's clear why the problem occurs every morning on my PC, because Windows does a HD backup of all my data each night. Is there a way to disable disk caching in XP to verify your theory? By the way, I removed "(minimized window)" from the bug description because the problem is not limited to that case. (For some reason this bug was assigned to me yesterday though I did not request or agree to that and I'm no expert, just an ordinary user ...)

AFAIK, the age-old settings for controlling disk cache work in XP as well. In your Windows folder, there will be a system.ini file. If it has a [vcache] heading already, put the settings under it; if not, add it. Try something like: [vcache] minfilecache=1024 maxfilecache=1024 which will make the cache size 1MB. There's probably a setting to disable it, but limiting the size should do for this purpose.

Limiting the cache will only serve to reduce performance on apps accessing a lot of data on disk. For instance, the mozilla build doesn't require a ton of memory, but having a large disk cache available really speeds things up. All the include file data can be kept in memory. It might serve as an interesting diagnostic, though.

Michael: As fas as I understand, the system.ini file is for legacy 16-bit apps only, so I didn't use that to adjust the disk cache. Looking around on the web, I found that XP seems to control the disk cache with the following registry value: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management\IoPageLockLimit (DWORD, cache size in kilobytes) Interestingly, that value didn't exist in my registry at all, so I added it and set it to different low values: 0 KB, 1 KB, 512 KB, and for comparison a large value (256 MB), then rebooted each time and repeated the "Restore Mozilla after a lot of file copying" test. However, I did not notice a significant change, the problem remained visible in all cases. Then I activated the option "DisablePagingExecutive" (found in the same registry branch, changed from 0 to 1), but this didn't remove the problem either. Since the amount of performance loss always varies a bit, I cannot guarantee that the changes had *no* influence, but obviously the problem could not be removed by a low disk cache. Maybe this helps anyway for the diagnostics.

In response to comment #234, you folks may be on to something. Mozilla experienced no problem when I left it open all night and browse around in the morning. Then I had to do the CD burning, so I copy all of the file off of the CD onto the HD since I only have one CD drive. Then put in a new blank CD to be burned. Once the CD burning was done, I haven't touch Mozilla for 30 or 45 minutes and unminimized it, it took a while to unminimize. I have not yet deleted the file from the HD. 30 or 45 minutes is enough time for the virtual memory to take care of itself. I use WinXP with 512 MB of RAM and 9 GB of HD with 2.78 GB free.

Joerg, Zook: Re comment #238: paging/swapping out is being mentioned starting with comment #4 and not a very new idea. Re comment #225: > [we] might get the impression that nothing is done [...] Did it come to your mind that maybe there is actually nothing being done currently? For doing something there is always somebody necessary who does it. > I recommend to remove "(minimized window)" from the bug title Finally you did it yourself, but did you consider the fact that this part was added to the summary due to all the duplicate bug reports which often included "minimized" in their summary? This addition should - and did - help decrease the number of duplicates being reported. > It surprises me that [this] has still not been labelled as a blocker ... It does not surprise me because it seems to be a problem that is not easily fixed. If bugs with no fix in sight for months (or no fix without changing the whole way Mozilla works) would block releases, no releases would me made for months. You surely have read comment #199, haven't you? It also does not block you from using Mozilla. I know these seconds hurt (I also don't like it), but the definition of a blocker is different. Re comment #234: > For some reason this bug was assigned to me Well, after demanding response from "the developer(s) working on this bug", changing the summary etc. aren't you surprised that you look like the mighty driving force for this bug? Demanding progress in open source means stepping in and filling the gap. Congratulations! Re [other comments, e.g. comment #145, comment #154, comment #191, comment #200, comment #214, comment #220,....etc....]: > [this bug is bad and should be fixed] [I'm sadly switching back to IE] > [This is a serious bug] [WHY IS MOZ DOING THIS SO BAD] [Fix this bug!] This is no newsgroup!! Because of such nonsense this bug has more than 200 comments and is nearly useless - or have you all read every comment before posting? Things are repeated over and over, knowledge is lost, sometimes rediscovered as "new" later... It's just sad how poor some people's knowledge of how bugzilla is supposed to work is. Yes, this comment does also not help solve the problem, but it might (hopefully) prevent several even more useless ones from being written. Nothing against_really_ helpful comments (there are several ones), but please be sure your's is one before hitting "Commit"!

Andreas Kunz from Comment #239 made a point about Comment #4. It had eluded me because of so many non-sense comments that I no longer remember the true meaning of it.

Update from my previous comments: I've just built a new machine. AMD 2500 chip (2+gig mhz) fast 333 motherboard with fast 333 memory (512meg), new 80 gig hard drive, fast ATI video card. The minimize bug is (if possible) even worse on this rocket machine (or it just seems worse, since all other programs are twice as fast now, and Moz still slogs through the mud). I had hoped on this new machine, all the Moz sloggyness would vanish, but alas, it's just as bad as ever. I can't tell from any of the comments here, but is ANY progress being made on this very aggravating bug?

I get this problem too. I have 384 mb of memory which should be enough for efficient memory swapping but I still recieve this bug .

I too have this problem and it's the main reason I switched to Opera as my default browser. I prefer Mozilla Firebird but this bug (Which only happens with Firebird) is a major annoyance. I'm really hoping that this gets fixed but seeing how long it has been I'm kinda doubtful now. Seems it would require more work than the devs are willing to put in to this non-blocking issue. System Specs: 1 Gig PC2100 RAM Dual 2.4G Xeons (HT enabled) 2xCheetah 15000 RPM drives in RAID-0 Config (Browser runs off this) Windows XP + SP1 and all the latest patches

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

It may be of interest that OpenOffice (I have version 1.0.3) shows the same problem on my PC, though the delay is much shorter than with Mozilla. As far as I know, both programs draw their user interface themselves without using a lot of Windows GUI function calls. Maybe this helps to track the problem down.

I have been doing some research on this bug for quite some time (from time to time). I just happen to saw an useful article on how to use the Windows NT Kernel Debugger at "http://www.informit.com/content/index.asp?product_id=%7B0B13BCB2-74F2-4131-8648-E11E05F4A4D9%7D". This article is very general and very lengthly, all we only need to do is to look at the disk activity section. Not too familiar with the debugger myself but I believe it would help to narrow down the problem to certain features that is responsible for this bug. I'm going to give this a shot. Keep me post on the development progress on this bug. No useless comments please.

I managed to capture a log of what files mozilla 1.5b was trying to access while waiting for the window to appear after leaving it alone for a long time. It's not complete, as it took time for sysinternals filemonitor (www.sysinternals.com) to start up, but something about the log struck me as interesting: Over the course of about 45 seconds while mozilla was non-responsive, there were very few accesses to the swapfile. Far more accesses were made to font files. There were many pauses between accesses to fonts with no disk activity whatsoever; not even to the swapfile. Might it be the case that the pausing has something to do with fonts, rather than paging? I'm running mozilla 1.5b on windows XP, 512MB RAM, 256MB swapfile, mozilla (post restore) 80MB working set, 320MB VM size. 25 windows, 200-odd tabs open.

Hopefully this is useful in some way. If not, sorry for wasting everyone's time. Tab separated text, should import into a spreadsheet program for easier viewing. What I find interesting is that there are several accesses with many seconds's pause between them but no other accesses (for example 155-156 is a gap of ten seconds; 205-206 14). Mozilla became responsive again some time around 22:24:50 or so.

That's an interesting observation about pinging the font files repetitively. I have a couple of questions about the filemon data: 1) was this done in the 'advanced mode' setting? If not, you won't see paging activity [by design]; 2) why is the swap file called WIN386.SWP? On NT/2K/XP isn't that normally called 'pagefile.sys'? Is this an XP that was upgraded from a win9x install?

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

Perhaps this extra info may tweak someone's head. Does the Virtual KB seem reasonable? Do the Fault Counts? Do the GDI's seem reasonable? Does the number of Modules? Handles? The size of the Handle files? Hope this helps. P.S. Windows Task Manager's VM Size only showed 64,100. - Mark

Well, I don't know if the bug has been officially fixed but I downloaded and installed the latest 0.7. I'm running a version optimized for my P4. The slow restoring problem has disappeared or is so small as to be unnoticeable.