Closed Bug 76831 Opened 24 years ago Closed 19 years ago

Slow startup after long periods of inactivity (minimized window or other)

Categories

(Core :: XUL, defect, P4)

Product:
Core
Component:
XUL
Platform:
x86
Windows NT
Type:
defect

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta3

People

(Reporter: st8, Assigned: brendan)

References

Details

(4 keywords, Whiteboard: [adt2 rtm] [swapped to disk] [READ COMMENT #206 AND #353 (plus the bugzilla etiquette) before commenting])

Attachments

(11 files, 1 obsolete file)

Application to hog memory
4.20 KB, application/octet-stream
Details
patch
1.23 KB, patch
Details | Diff | Splinter Review
Try to force the right amount of memory to be pagead in
1.82 KB, patch
Details | Diff | Splinter Review
Log of mozilla 1.5b's file accesses while recovering from inactivity
33.54 KB, text/plain
Details
TaskInfo2003 information concerning Mozilla
70.22 KB, text/plain
Details
don't reduce working set when minimized, configurable
5.03 KB, patch
emaijala+moz
: review+
bryner
: superreview+
chofmann
: approval1.7+
Details | Diff | Splinter Review
Make mozilla on win32 explicitly swap its working set back in
6.87 KB, patch
Details | Diff | Splinter Review
Performance monitor graph for mozilla coming up (30 seconds)
14.84 KB, image/png
Details
Performance monitor graph for winword coming up (~5 seconds)
14.28 KB, image/png
Details
Perfmon graphs for FF & Mozilla
81.05 KB, image/png
Details
fix
2.08 KB, patch
pavlov
: review+
jst
: superreview+
brendan
: approval1.8b3+
Details | Diff | Splinter Review
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
*** 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...
URL: ANY
Keywords: arch, hang, helpwanted, perf
->Apps
Assignee: asa → pchen
Component: Browser-General → XP Apps
QA Contact: doronr → sairuh
QA Contact: sairuh → claudius
nav triage: moving to m1.0 since not sure if this happens for lots of users.
Keywords: nsbeta1+
Priority: -- → P4
Target Milestone: --- → mozilla1.0
don't think I'll get to this by mozilla1.0, marking mozilla1.2
Target Milestone: mozilla1.0 → 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. ***
Blocks: 74634
This is getting duped a lot. Updating summary to be more self explanatory.
No longer blocks: 74634
Summary: maximise the brower window, takes a long time for browser to display → slow startup after long periods of inactivity (minimized window)
Blocks: 74634
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
Assignee: pchen → trudelle
QA Contact: claudius → sairuh
Target Milestone: mozilla1.2 → ---
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.
QA Contact: sairuh → jrgm
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
Assignee: trudelle → hewitt
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
Assignee: hewitt → morse
Keywords: nsbeta1
nsbeta1+ per Nav triage team, Nav2, ->1.0
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [nav2]
Target Milestone: --- → mozilla1.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.
OS: Windows NT → All
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..
OS: All → Windows NT
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
Whiteboard: [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)?
Blocks: 108795
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?
Keywords: mozilla1.0
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
Whiteboard: [adt2] → [adt2 rtm]
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; }
Status: NEW → ASSIGNED
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.
Assignee: morse → bryner
Status: ASSIGNED → NEW
Status: NEW → ASSIGNED
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.
Attached patch patch — — Splinter Review
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.
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.
Target Milestone: mozilla1.0 → mozilla1.2beta
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 :-(
Blocks: majorbugs
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.
Keywords: hang, mozilla1.0 → mozilla1.4
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.
Flags: blocking1.4a?
Keywords: arch
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.
Flags: blocking1.4a? → blocking1.4a-
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.
Flags: blocking1.4b?
Flags: blocking1.4?
Target Milestone: mozilla1.2beta → ---
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
Blocks: 639, 66381
Stupid me... Sorry.
No longer blocks: 639, 66381
Depends on: 639, 66381
OS: Windows NT → All
Hardware: PC → All
No longer depends on: 66381
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.
Flags: blocking1.4b?
Flags: blocking1.4b-
Flags: blocking1.4?
Flags: blocking1.4-
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
OS: All → Windows NT
Hardware: All → PC
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.
Blocks: 203448
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.
Assignee: bryner → bugzilla
Status: ASSIGNED → NEW
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.
Summary: slow startup after long periods of inactivity (minimized window) → Slow startup after long periods of inactivity
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.
Flags: blocking1.5b?
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.
Summary: Slow startup after long periods of inactivity → Slow startup after long periods of inactivity (minimized window or other)
Whiteboard: [adt2 rtm] → [adt2 rtm] [swapped to disk]
Flags: blocking1.5b?
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. ***
Blocks: 220952
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.
I take it back. I just experienced it again but it seems to take longer to get to the point where it restores slow. Also it still faster than it was but when it does it, it's very noticeable.
*** Bug 206341 has been marked as a duplicate of this bug. ***
If you want to see this bug in the worst intensity that's probably possible, get the X-Plane flight simulator (the free demo from www.x-plane.com should do the job). Start and minimize Mozilla, then start X-Plane and shut it down again. Then restore Mozilla - it's almost frozen to death on my system (Win XP, 512 MB, Moz 1.4). It takes several *minutes* to return to normal.
I noticed that if you change the process priority to high sometimes Mozilla "awakes" faster. A few days ago I opened the Task Manager while Mozilla was slow reloading, and noticed that he was increasing the memory used bue at small chunks (usually other programs take bigger chunks) while the HDD light was permanently on, so I increased the Mozilla process priority and Mozilla started to take bigger memory chunks (or the same size chunks but faster). This was after closing a game (Quake 3), and the processor was almost unused (Mozilla wasn't taken even the 50% of the CPU), and all open process had normal priority but taskmgr, winlogon and CSRSS. I have an Athlon 1700+ with 512MB using Win2k SP3 and Mozilla 1.5. I also noticed that Mozilla goes slower than other programs if any process is taking the 100% of the CPU. In that conditions IE and other programs take more time to load that with and idle CPU, but Mozilla takes ages to start or show a page. This behaviour is like Mozilla have a lower priority than other "normal" processes.
Assignee: bugzilla → jag
QA Contact: jrgmorrison → pawyskoczka
*** Bug 227654 has been marked as a duplicate of this bug. ***
Some of the bugs that are duped to this one, mentions a slowness after a sleeping period. They might suffer from the swapping prioblem too, but they might have their specific problems on top of that. Compare for example with bug 197863 (High CPU usage after waking from sleep because of timers). The solution was only implemented for the Mac at <http://lxr.mozilla.org/seamonkey/source/widget/src/mac/nsToolkitBase.cpp#219>, but can we use a similar thing for Windows ? See also bug 639.
I agree with Jo Hermans. Tough I also experiment the slow restart of Mozilla after long time being minimized or inactive (specially after being playing with games), the behaviour is different of the problem that happens after restoring, since then the entire system freezes, not only Mozilla (this was described in the bug 206341). Also, I only notice that behaviour when I left open pages with some Macromedia Flash content (see the bug 206341 for a detailed description). By the way, after upgrading to Mozilla 1.5 the suspend/hibernation problem almost disappeared in my Windows 2000 system, and mitigates in my Windows XP system (now the delay is 1 minute at much instead of 2 or 3). The problem of slow start almost minimizing affects my systems more or less the same. I have installed Flash 7 now, but I think that it was the same behaviour with Mozilla 1.5/Flash 6.
Can it be cured by www.7-max.com ? Hello I am evaluating 7-max (from the makers of 7-zip) and with both Firefox and Thunderbird running, they do seem zippier. I wonder if some of you could confirm my suspicions, and if they are correct, would they accept a "strategic alliance" ? :) Chris
Comment #260: Replacing Windows components (even only temporarily in memory) is a BAD idea.
It might be an option for users that want to install that, but I wouldn't want to make such a change at install time of an application. And moving from 4k to 4m pages have other implications. Given each app has a finite address space, it might use up the address space quicker. While there might be a perf boost, I would bet the problem still exists. Paging might be more efficient since depending on how the Windows paging system reads/writes pages. Writing 4meg at a time would be more efficient than 4k at a time. I still say the biggest boost would probably come from the addition of Shaver's generational GC work.
I've just found a way to reproduce the behaviour on demand: 1 - open a goodly number of tabs/windows 100 tabs over 10 windows should do on a 0.5Gb machine. 2 - Open the display properties control panel, and change the colour depth 3 - when asked if you want to keep the setting, answer 'no'. At this point, mozilla will exhibit the 'slow startup' behaviour. In addition, all the taskbar icons change from the individual component's icon to a generic 'red mozilla head' icon. It would seem that mozilla is doing a lot of unnecessary repainting/reflowing and is not usable until it has done so. I don't know enough about mozilla to say why this is happening. A log of mozilla's file activity shows it doing a lot of accesses to the fonts folder. You'll notice a lot of disk activity, but investigation with something like filemon will show that this is caused by explorer.exe rebuilding its icon cache. After repeating the procedure a few times, I was able to get mozilla to 'slow startup' without accessing the swapfile at all. In my opinion, this has nothing to do with paging. I suspect this is happening on NT after periods of inactivity, because NT has more than one desktop. Under NT, the screensaver is executed on the 'secure desktop', over the top of the logon/unlock screen (so crashing/killing the screensaver does not unlock the computer). I suspect the desktop change (like the colour depth change) is triggering this repaint behaviour. re comment 249, the swapfile has been changed from the default filename, so as to make dual-boot XP and 98 use the same swapfile. The log was taken under XP, advanced mode off. I can send you an advanced mode log if you are unable to reproduce using this method, but I'm reluctant to post it on bugzilla, as explorer.exe trawls most of my hard drive looking for icons.
Has anyone tried with a static build to see what difference does it make if there aren't dozens of dlls to swap in?
I know that alecf had been working to reducing the DLL count, so I assume there were some numbers suggesting it was a good thing. Also there is or was a static lib build option I thought.
*** Bug 231232 has been marked as a duplicate of this bug. ***
I have just found http://support.microsoft.com/default.aspx?scid=kb;en-us;293215 via a comment at http://weblogs.asp.net/oldnewthing/archive/2004/03/17/91178.aspx That KB article seems to imply that intercepting SC_MINIMIZE and turning it into SW_SHOWMINIMIZED should prevent the application from being paged as much as it would with the default behavior of using SW_MINIMIZE. Since I'm not a Windows programmer (I'm not even a Windows user) I don't know if this will help or not, but since nobody mentioned it yet, I figured it might be useful. Sorry for the spamming if it isn't (but if you are in the CC list for this bug after all this time, you already expect it, right? ;-)
That's an easy change. It probably fixes this bug, but makes a real memory hog out of Mozilla. On my machine with an optimized build, according to the Task Manager memory usage is (in Megs): prepatch patched launch one window, about:blank 18.3 18.2 cnn.com in one window, mozilla.org in a second 25.0 24.7 minimize mozilla.org 8.2 24.7 minimize both 1.8 24.7 restore both 10.7 24.7 In the unpatched build, memory usage doesn't return to its 25 Meg peak until a new page is loaded.
Comment on attachment 144180 [details] [diff] [review] don't reduce working set when minimized Well, I think this patch might be a great thing. I find it stupid to trim the working set when an app is minimized -- like I didn't need it anymore or it didn't do anything in the background. Might be a good idea to check this in when the trunk is opened again to gather feedback. However, it still puzzles me how swapping in can be so slow sometimes. I've witnessed this on my Athlon XP 2400+ 256MB WinXP system when there are two people logged in having Mozilla and other programs running. It can take something like two minutes of horrendous swapping for the Mozilla in the previously inactive session to start responding again when the user is switched.
Whoa!! The patch would need to be tested a couple of times or more by different users/machines to see if it is not causing any problems and/or to see if the problem is actually solved before checking it into the trunk.
And you might want to make it a configurable option (maybe a hidden one?). I can see some folks preferring the delay to the constant memory use. It certainly is a non-ideal solution, IMO, so its desirablility would likely depend on your particular memory resources/needs.
maybe someone could provide a teste build. Dan?
25 meg is a small price to pay for this most annoying bug. Even if I had to run a one-off build. I'll gladly test a build of this as I've been suffering from this minimize bug terribly from the beginning. WinXP and Win3k
danm proposes landing a variant of this patch that makes the change depend on setting a ui-less preference. Need a patch doing that to proceed. Nominating for 1.7 final. /be
Flags: blocking1.7?
Same as comment 268, but this version is configurable using a pref. It behaves as it always has if the pref is missing or true. (Oh and, ahem, I cleaned up a deprecated use of nsIPref while I had the hood up.) I don't know that this will fix the thrashing problem, but it seems worth finding out. I don't have a suitable server for posting a test build. Perhaps some people affected by this problem could spin their own build. Or maybe we can get this configurable version into the general 1.7 release.
Attachment #144180 - Attachment is obsolete: true
Attachment #144414 - Flags: review?(ere)
Everybody seeing this bug: I made a build with that latest patch and made it available at http://i08fs1.atis-stud.uni-karlsruhe.de/~s_kunz/mozdev/bug76831.zip My bandwidth is large, but not unlimited, so please send me a short note (by e-mail) when you're downloading it, so I get a rough estimate on how much bandwidth is used. After downloading, you have to set the pref "config.trim_on_minimize" to "false" to activate the patch, at least that's how I understand the patch. DanM, please correct me if this is wrong. Thank you and good luck for testing this!!
(In reply to comment #276) > After downloading, you have to set the pref "config.trim_on_minimize" > to "false" To explain this: you have to access about:config and create a new boolean pref with this name, value being false. I just tested it and it works (Task Manager shows mem values on minimize that are very different from when this pref is set to true). What I also noticed when testing, was that this tree of mine had a preliminary patch for bug 155325 applied. But be assured, apart from that it is a fresh cvs pull from a few hours ago and that patch should not affect testing. (it is about showing scrolling errors when you have many tabs open to prevent them to get to small or to fully disappear on the right. This patch is not ready, so you don't need to comment in that other bug when you find small glitches).
(In reply to comment #276) > I made a build with that latest patch and made it available at > http://i08fs1.atis-stud.uni-karlsruhe.de/~s_kunz/mozdev/bug76831.zip > My bandwidth is large, but not unlimited, so please send me a short note (by I downloaded your test build and it's available on: http://i.love.pinknet.cz/aha/bug76831.zip
Comment on attachment 144414 [details] [diff] [review] don't reduce working set when minimized, configurable Looks good, r=ere
Attachment #144414 - Flags: review?(ere) → review+
>>After downloading, you have to set the pref "config.trim_on_minimize" >>to "false" to activate the patch, at least that's how I understand >>the patch. DanM, please correct me if this is wrong. In respond to comment #276 and for comment #278, which file exactly for the zipped archived?? I couldn't find one that contain the word, "config.trim_on_minimize". I'm sure everyone else would want to know this too. By the way, I can test this with the disk activity for WinXP monday morning to see how it goes and will let you know.
(In reply to comment #280) > In respond to comment #276 and for comment #278, which file exactly for the > zipped archived?? I couldn't find one that contain the word, > "config.trim_on_minimize". Didn't I clearify this in comment #277? There is no such entry yet in a prefs file, you can set that pref easier anyway by typing "about:config" into your URLbar and hitting return. Right-click on the appearing list, choose "New" - "Boolean", then enter "config.trim_on_minimize" for pref name and then "false" for its value. What I didn't mention: you might have to restart Mozilla after adding this pref, maybe not, but you're on the safe side if you do. I did only a short test, there was no lag with the patch, almost no lag without the patch. I obviously didn't manage to swap it out enough. Not enough difference to say if this only was what I _wanted_ to see.
Yes, after setting this pref using about:config, be certain to quit and restart. The preference is read only once, early during app initialization. (Your other choice is to edit prefs.js using a text editor.)
Will this pref also be read from user.js? Modifying prefs.js is not recommended.
I am no longer able to reproduce this bug with Mozilla 1.6 which I downloaded at the time of that Mozilla 1.6 release. So, I can't test the last week build with the patch attached. Hopefully someone else who have this problem can come forward to test it and let us know how it go. By the way, I think it would be wonderful if this patch is checked into the trunk because it could help to ease or to resolve other bugs not related to this. Well, if that doesn't hurt other bugs or produce new bugs.
(In reply to comment #283) > Will this pref also be read from user.js? Modifying prefs.js is not recommended. Answering my own question, the pref does get read from user.js if it is set there.
After a few days of looking around w/ Mozilla, I found that if I left the JavaScript Console running in the background while MS-Outlook in the foreground. Left it there like that overnight then try to bring the JavaScript Console to the foreground, it took almost 10 minutes for it to become responsive. In the task manager, it showed that about 200 MB of memory/paging was used to bring the JavaScript Console back. Once it become responsive then 200 MB of memory/paging goes away. So, I thought perhap this is it for testing. So, tested it w/ and w/out the patch for a couple of overnights. There I found the JavaScript Console become responsive instantly, or by a second. Seem like the patch fix did the trick. By the way, I'm using WinXP with 512 MB of RAM which would have been kind of odd without the patch fix. So, anyone want to super review the patch? Anyone want to try to get it checked in? I don't think it would hurt to give it a shot.
Comment on attachment 144414 [details] [diff] [review] don't reduce working set when minimized, configurable That's odd. I wouldn't expect this patch to affect windows that are merely backgrounded, rather than minimized. I think it needs more testing. But maybe we're onto something. Cesar, thanks for finding that bit of Windows trivia that made the patch possible. And thanks Zook for running it through its paces. It's worth getting sr=ed and I think put into 1.7 where it can reach a wider audience, since it's inactive by default, anyway.
Attachment #144414 - Flags: superreview?(bryner)
Attachment #144414 - Flags: approval1.7?
Doesn't making it off by default make the patch worthless ? Most users will be unaware of the setting and will continue to be affected by the performance hit. If you want it to receive more attention (testing) perhaps ask one of the unoffical builders on mozillazine forums to include it (set to on) in their builds and let it get thrashed out that way.
(In reply to comment #288) > Doesn't making it off by default make the patch worthless? This patch causes Mozilla to use dozens of Megabytes more when being minimized. Are you joking or do you really expect users will like it behaving this way by default? Apart from that the effectiveness of this patch has not been completely tested, there is only about one positive response. That's not much of a legitimation to get it into a final build without ever having been in a beta. > Most users will be unaware of the setting and will continue > to be affected by the performance hit. Of course, but 1) the default can still be changed later and 2) it's certainly nicer to be slow than to make everything else slow. Imagine the bad press when people say "Mozilla slows your system down by intentionally hogging RAM with the aim to run faster than other applications!". I doubt this should ever be on by default. (BTW, the real bug - paging in is extremely slow - is not fixed by this wallpaper-like patch.) > If you want it to receive more attention (testing) perhaps ask one of the > unoffical builders on mozillazine forums to include it (set to on) in their > builds and let it get thrashed out that way. Huh? With this patch it's as easy as setting a pref for everybody having a standard build to test this. You think people are more willing to download a dozen MB than to set a pref in 1.7? If you just want to have more people test this, they can as well download this build here and set the pref. But of course making the test build public in the mozillazine forums isn't a bad idea. Please feel free to do so! However, this bug has 87 votes and about as many people cc'd. One would assume they are interested in getting this bug fixed, right? Then how comes that I only know of two people having downloaded the test build from my site for testing? Maybe my message about bandwidth caused the majority of the testers to download from Adam's mirror, but even if so, there (almost!) hasn't been any testing response. People, voting for bugs is nice, but don't expect it to actually help fixing bugs... (I have an excuse: my mainboard is out of order and I'm working with a Pentium 120 and Win95 right now...)
I've been running this patch for a week or so and have had great results. There haven't been any instances where firefox hung, where before this, I found it a few times a day.
If a user has a low-memory system (i.e. 128 MB or less) then it is absolutely a BAD idea to not allow Mozilla to give up it's non-essential paging space while minimized. Many people keep they browser minimized when not in use so that it can continue to check for E-mail, refresh web pages, etc. Sure, if you have lots of spare RAM on your machine it might help you, but I think we should first consider the possibility of how memory management is handled in Mozilla as a root cause. For instance, you can get Mozilla to expand to 128MB of real and VM usage by loading a very large .JPG file.
One clarification: this patch does _not_ prevent Mozilla from releasing memory for other apps (that is, being swapped out). It's just that it won't happen before it's necessary, and only the needed amount of memory is "moved" from Mozilla to the other program. This is the same thing that happens if you leave Mozilla to the background and start another program.
Let me just say I've been running Andreas Kunz's fix build and it's fantastic! I'll gladly sacrifice the 20-50 megs ram to see this problem fixed. I've run it for hours on end (minimized with a dozen or more tabs) and it pops up instantly. I'm keeping this build as my default. Thanks Andreas!
No it doesn't prevent Mozilla from being swapped out. But it will cause memory to be paged out in other applications that aren't minimized, that ordinarily wouldn't have had to. Generally the idea is that if an application is minimized, it isn't being used, and that it's better to ask for memory from applications that are minimized than ones that aren't. I think the pref is an excellent idea, but I think turning it on by default could be a mistake unless the majority of Mozilla users only run Mozilla and no other memory hungry applications. It would be interesting to know what the percentage of users who leave their browser up and running for long periods of time as well as the percentage of users experiencing the problem. I'd just like to see that if we would turn this on by default we wouldn't be ticking off an equal number of users. I know for my usage, I'd have to go back and turn it off.
I agree that wider audience is neccessnary to test this out. We have like less than 100 people who are CC's here as oppose to 10,000 people out there on Internet. So, more opportunity out there. The feature is off by default, contain only a few lines of codes, so it is not to kill anybody over it. An analogy of this would be a heart patient with or without a pacemaker. Just that symptoms are reduced. This patch could help to connect the dots for other bugs not related to this, so this is a plus! Everybody win! There is no loser here!
I downloaded Andreas' test build and tried it with the ultimate memory killer application - after loading and closing the X-Plane flight simulator, my standard Firefox reproducibly got very slow for 20-30 seconds. The Mozilla test build reduces this time to maybe 3-5 seconds, which I find acceptable and is comparable to some other applications. Thanks for the great work, especially to Andreas! If someone could provide a Firefox build with this patch, I'd gladly test it, too. Still I hope the underlying paging problem will be addressed as well.
Since the problem is really aggravated by the so-called quick start feature which actually makes mozilla real dog.. It would be nice to have UI tick box right next to the "quick start" option in preferences for conservative memory usage. Not many people read mozillazine and/or release notes.
> especially to Andreas Don't thank _me_, I only compiled the test build. I consider Cesar Eduardo Barros the real "hero" - he had the idea for the patch in comment #267. And of course Dan M actually writing the patch. Thanks! I only hope this patch will not keep us from eventually finding out why Moz is paged in so slowly. But since we did not find out in years, I have no hope this will happen soon and am really happy to have this pref available. BTW: as already pointed out by ere, Moz _will_ be paged out, but only when it really needs to be. This means other applications are not slowed down that much, maybe it's not even perceivable.
In reply to comment #297 about quick start feature. Are you saying that if the quick start feature is enabled, it aggravate the problem? Mine is disabled the whole time.
I downloaded that patch but it's for Mozilla. Is there a Firefox specific patch that I can try?
Comment on attachment 144414 [details] [diff] [review] don't reduce working set when minimized, configurable You know, I'm really not a fan of the new pref interface needing more virtual method calls and null checks than the old interface. Not much to be done though; you're using the interface correctly. sr=me. Let's try to get some testing on this in 1.7 so we can make a decision about turning it on for 1.8.
Attachment #144414 - Flags: superreview?(bryner) → superreview+
Comment on attachment 144414 [details] [diff] [review] don't reduce working set when minimized, configurable a=chofmann for 1.7
Attachment #144414 - Flags: approval1.7? → approval1.7+
Stormblade (comment 300): The patch is general and applicable to both Mozilla and Firefox. And Thunderbird and every Windows app, for that matter. Brian (comment 301): I've never understood why the new pref interface was better, either. But somebody said "deprecated," so here we are. Patch is checked in to the trunk. So reiterating, it causes no change in behaviour by default. But if you're suffering from this bug and you're uncommonly knowledgeable, you'll be able to set a pref which will prevent Windows from reducing the application's working set when minimized. Please do give it a try and report your results. To set the pref, navigate to about:config. Create a new boolean pref using the content area context menu. Its name is "config.trim_on_minimize". Set its value to false. Exit and relaunch the app. This capability will be in the nightly builds beginning tomorrow, and barring accidents, in the 1.7 final release. Thanks again to Cesar, who doesn't even use Windows, for discovering the trick.
Given the CC list size and number of comments in this bug. Would it be a good idea to spin off a separate bug to receive input from the impact of this patch? Then only people really interested would be putting themselves on the CC list and it would make it easier to get to this information.
(In reply to comment #282) >The preference is read only once, early during app initialization. (Your >other choice is to edit prefs.js using a text editor.) So, not switch-profile safe ;-)
Since the patch had been checked in to the trunk on 04/01/04 and the roadmap showed that the Moz 1.7 would be branched from the trunk on 04/02/04. Yes, we know the roadmap is only a guideline and sometime doesn't happen on-time. So, is there a valid reason that this patch should be blocking the Mozilla 1.7 release as it is right now? Unblock it?
Flags: blocking1.7?
Furthermore, does this patch do anything at all on the Linux OS, or is it Windows-specific? If it's Windows-specific, then Mr. Valem's suggestion about a spinoff bug should be Windows-themed and this one should be kept open to fix the problem on ALL operating systems.
(In reply to comment #307) > Furthermore, does this patch do anything at all on the Linux OS, or is it > Windows-specific? This bug is Windows specific (as suggested by the OS field and the first about 200 comments). Only then somebody said that unminimizing on Linux also was not _that_ fast. But this was clearified in comment #206 and comment #207 (which you really should read).
Setting the pref to false is working like a charm for me ! Thanks all ! This should be false by default. Mozilla should not attempt to override the OS memory management. Windows will automatically trim mozilla process memory (and other processes as well) when it's needed (ie when running low on memory). There's no need to trim the memory if there's plenty of MB RAM FREE and Mozilla currently has no way to know about this, only the windows OS knows.
But this is what Microsoft recommends, and what every other application running on Windows does to be a good citizen. If applications didn't do this, then every application is on even footing for getting memory reclaimed. Which is generally not a good thing. The act of minimizing was used to allow intelligent reuse of memory so that active applications were allowed to keep the ram they had and not be forced to fault it back in. I really think having Mozilla be a good neighbor by default is better than having it be a bad one by default.
oops, sorry ... I've just tried minimizing IE and Winword and their process memory is trimmed on minimize. I misunderstood mozilla behaviour. David: you're right I reverse my Comment 309 conclusion ie the current default pref value (true) is correct, Mozilla just match Windows OS policy. The initial problem remains.
(In reply to comment #310) > But this is what Microsoft recommends, and what every other application running > on Windows does to be a good citizen. If applications didn't do this, then every > application is on even footing for getting memory reclaimed. Which is generally > not a good thing. The act of minimizing was used to allow intelligent reuse of > memory so that active applications were allowed to keep the ram they had and not > be forced to fault it back in. > > I really think having Mozilla be a good neighbor by default is better than > having it be a bad one by default. > True, but Mozilla plays the game like a retarded monkey, otherwise we wouldn't be having this conversation. I say, have this new pref disabled by default but have a damn clear UI setting to turn it on. Actually, it would be kind of embarrassing. The developers would be admitting they wrote something they can't fix correctly. Still, I'll take it.
Keywords: fixed1.7
Can we get this switch documented (what it is, how to activate it) in the next Release Notes? I've already forgotten what the setting was called (I know, it's in the history of this bug . . . somewhere!)
Could someone summarise here? I just can't sit here and read the vast number of comments in this bug. I'm seeing the same problem with mozilla's process size growing from 20Mb to 60Mb paging in at 200kilobytes/sec - horribly slow. You can see the process size growing in the task manager, under the process list. I'm running 1.7b. I gathered from some comments above that I need to put this in prefs.js, is that correct? Is this patch in 1.7b? user_pref("config.trim_on_minimize", false);
relnote keyword added (sounds like a good idea to make this public) (sent private mail to David about etiquette; 1.7b does not feature this patch, only current nightlies and upcoming 1.7 candidates)
Keywords: relnote
Will the patch automatically go into the next (official) Firefox and Thunderbird releases, too? If not, could someone of the developers make sure it does?
Downloaded the nightly build (4-13-2004). Installed and turned on the option. To test it I minimized it and downloaded a ton of stuff overnight. This has always resulted in slow restore. Not anymore :) It came up like I just minimized it. Woohoo! Don't know if this is a "fix" or work-around but I'm happy with it.
I don't know if it is just me or if it is what I'm really seeing. See, there is a virus on the computer that was caught and I had to runn the Symantec Anti- Virus to see if it is really caught 'cause everyone else have it. So, once it was running, Mozilla had slowed down, so do MS-Outlook and Outlook Express. I decided to try it with this patch fix and see what it look like. To my surprise, Mozilla is quicker while the hard disk is thrashing because of the scanning by the Symantec Anti-Virus. Thought you may want to know.... Yipee! Let's celebrate!! (Popping cork off of the wine bottle!!!) :-) But hey, I don't know if it is what I'm really seeing it or is it just my head that play trick on me.
What is the recommended way to activate the patch in Thunderbird? I downloaded the latest nighty build (April 15). Of course there's no way to enter "about:config" in it ... or is it?
I just downloaded version 1.7RC1 for Windows. The documentation says that config.trim_on_minimize is now available. However, when I do about:config config.trim_on_minimize is not present.
I just downloaded version 1.7RC1 for Windows. The documentation says that config.trim_on_minimize is now available. However, when I do about:config config.trim_on_minimize is not present.
read comment #277
Added to release notes, removing keyword (as per IRC talk with Asa).
Keywords: relnote
If this workaround provides the relief we're all looking for, I'd request to see it added as an Edit/Preferences option, default OFF, unavailable under Win9x, in v1.7.1+. A note could be put underneath the option saying to turn it off if performance of other applications suffers and not to use it unless you have at least 256/384/512MB RAM (not unusual on today's PCs) and so on. The goal would be to word it in a way that gives the option a positive spin. I know it wouldn't look pretty and all of this is essentially a "hack", but what's the difference between this and Quick Launch? Quick Launch follows the same principle of using extra memory/CPU cycles when the browser's not being used for better performance...
In fact the preference should be sitting right next to the so-called quick launch. If you turn on the slow launch and work all day, you're almost guaranteed to be hit by the bug, hard.
(In reply to comment #0) > 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 I have the same problem. I work with WinXP and 512MB RAM and this is happenning even if I do nothing so memory isn't full !!!
(In reply to comment #0) > 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 I have the same problem. I work with WinXP and 512MB RAM and this is happenning even if I do nothing so memory isn't full !!!
Yipiee--everyone loves a good hack! Sheesh...this whole thread of discussion is rather embarrassing--if all developers made this kind of move with their Windows-based software then we would all need to run machines with 512MB+ of memory just to do basic tasks. I don't think a hack-type fix should *EVER* make it into a permanent preference setting--if someone wants to tweak the about:config then go right ahead, but come on people--focus on fixing the problem not the symptom. In my humble opinion, of course ;-)
One more time: this setting does NOT force Mozilla to stay in the memory, it just makes Windows not force Mozilla to swap out when minimized. The net effect of this is that there isn't immediately so much memory available for something new when Mozilla is minimized, but the memory can be regained from Mozilla _if_ necessary. In reality switching this setting off can make the memory management more effective as there are quite a few things Mozilla does occasionally even if it's minimized. Or think about it this way: if you don't always minimize all Mozilla windows when they're not in use but leave them in the background, the effect is the same as turning this setting off. It doesn't increase the memory requirements.
>>I don't think a hack-type fix should *EVER* make it into a >>permanent preference setting--if someone wants to tweak the >>about:config then go right ahead, but come on people--focus >>on fixing the problem not the symptom. Sigh!! Who say this is a "FIX" to the problem? I don't see any comment in this bug report that say this is a "FIX" to the problem. Just that it need more testing to the wider audience and find out if this patch help or not, 'cause no one really know what the real problem is exactly!!
Well.. Actually this also happens on MacOS X platform, but it is not so noticeable as that on Windows XP. I think this problem is related to the host OS's memory management in some way. Other programs, for example, Adobe Acrobat and eMule plus, also have this kind of problem. So.... wouldn't it be good idea to check how the OS behave with its virtual memory?
at least on Windows, Mozilla has the problem much more severely than any other program, even programs that use a lot more memory.
Not exactly true. For example Microsoft's own Terminal Services client (at least the one that came with Windows 2000) sometimes exhibits the same behavior.
Good grief. This bug has been open for three years. If it takes that long for the devs to acknowledge the problem exists and to figure out a viable workaround, fine. Maybe in 6 years someone looks at the mozilla memory management routines and figures out why it behaves like a paralyzed otter in some circumstances. I think it's completely immaterial if there exists another program for windows which shows the same symptoms, I have never seen one myself so it's not exactly a common problem.
I observed "Memory Usage" and "Virtual Strage Size" of mozilla.exe by Task Manager(Process) on Win-2K. M = "Memory Usage" (=Real Memory) here after V = "Virtual Strage Size" here after (Test scenario and Result) (1) Start Mozilla Browser ==> (M-1) (V-1) (M-1) , (M-2) is usualy 10MB to 20MB (2) Repeat File/New/Navigator Window & close opened window. (2-1) File/New/Navigator Window (CTRL+N) Note: If you set HTML includes large image as Home Page, increasing storage size bocomes large. (2-2) Close the opened window ==> (M-2) (V-2) (M-2) > (M-1) , (V-2) > (V-1) [Incident-A] M and V increases on each window open but does not decrease on window close. (Note: Tab close decreases virtual storage size.) (3) Close all Mozilla windows except one, then Minimize last Browser window M decreases to almost 1MB but V stays same as before. ==> (M-3) (V-3) (M-3) nealy eaual to 1MB, (V-3) == (V-2) [Incident-B] M decreases to nealy equal 1MB on window minimize. (4) Return to original window size M increases but not so large as before. ==> (M-4) (V-4) (M-3) << (M-1) < (M-4) < (M-2) , (V-4) == (V-3) == (V-2) [Incident-C] Real memory is really freed by MS Windows only when window is minimized. (5) Reapeat and repeat step (2) & step (3) & step (4) You can probably reach 200MB virual storage size easily. [Incidents-D] = [Incident-A] & [Incident-B] & [Incident-C] - M increases on window open and decreases to several MegaBytes on window minimize. - M increases on re-activation but smaller than before window minimize. This size is nealy equal to Mozilla's "Working Set", probably. - V increases but never decreases. (6) Close last Mozilla window Even after Mozilla window disapeared, mozilla.exe stays in task manager for a while, and memory size reducing speed is not so high. This indicates memory clean up of MS Windows is not so efficient. [Problem-1] [Incident-A] says window close does not release virtual memory. [Incident-C] says real memory is released. But not freed really by MS Windows until window minimize. I do not know which bug is this problem. This is prabably one of the causes of Bug 212197 and Bug 215491. [Problem-2] [Incident-C] says real memory is released on window close by Mozilla but is not freed really by MS Windows until window minimize. Why? Mozilla's fault? MS Windows's fault? Or normal? [Problem-3] [Incident-B] says Mozilla does not keep "Working Set" in memory when window minimize. Memory Usage(Real Memory) does not decrease usually when window minimize of other applications such as Opera 7, IrfanView 3.90, GIMP2.0.1. If Mozilla was completely swapped out during minimized window, all virtual memory is probably swapped in again by MS Windows on re-activation of Mozilla. (This bug, too large virual memory size is Problem-1, though) [Summary and Question] Since memory management of MS Windows is not so well designed(poor I think), Mozilla is better to keep in memory even when window is minimized in order to avoid this bug. However, [Problem-2] indicates that no minimize will possibly not reduce Mozilla's real memory usage. This may cause peorfomance impact on entire system if this bug's circumvention is same as "no minimize". Which is the memory size this bug's patch keeps in memory, memory size displayed as "Memory Usage" before window minimize, or "Memory Usage" displayed after window minimize & re-activation("Working Set" size)?
(In reply to comment #335) > Since memory management of MS Windows is not so well designed(poor I think), > Mozilla is better to keep in memory even when window is minimized in order to > avoid this bug. There is nothing wrong with the Windows memory manager. Learn how it works. Mozilla is doing some major churning in memory when it restores. The way to fix this bug is to figure out what Mozilla is doing, and why, and remove that churn. Also, don't use taskmgr.exe to figure out performance issues with apps running on Windows. You can get much better and more useful information by using PerfMon - which is built into every system.
I've found that when I open a PowerPoint slide show (about 1MB and full of pictures), Mozilla swaps already to disk! But I've also noticed that Outlook doesn't do this !? Hope this could help you debug more easily without waiting a few minutes :)
Sun documented the JVM reaction to fragmented heap and GC. Read: http://developers.sun.com/techtopics/mobility/midp/articles/garbagecollection2/#16.2.6 "Another problem with an oversized heap is 'locality of reference'. This is related to the operating system, which manages memory. If the heap is larger than physical memory, parts of the heap will reside in virtual memory. Because the concurrent collector looks at the heap as one contiguous chunk of memory, the objects allocated and deallocated could reside anywhere in the heap. That some objects will be in virtual memory leads to paging, translation-lookahead-buffer (TLB) misses, and cache-memory misses. Some of these problems are solved by reducing the heap size so that it fits entirely in physical memory, but that still does not eliminate the TLB misses or cache-memory misses, because object references in a large heap may still be very far away from each other. " One other way to solve that is to use locked memory (non-pagable memory). I couldn't believe how fast were my programs when I experimented "Memory+" (a program that can unswap entirely a process in fraction of seconds, but sadly has hiccups that would crash my eclipse JVM). I Tried it with mozilla, lotus notes and also eclipse who is exactly suffering from the same problem (about 150 megs memory). So, if a stranger program can swap in 150 megs in few seconds, I trust mozilla can do it too.
Sun documented the JVM reaction to fragmented heap and GC. Read: http://developers.sun.com/techtopics/mobility/midp/articles/garbagecollection2/#16.2.6 "Another problem with an oversized heap is 'locality of reference'. This is related to the operating system, which manages memory. If the heap is larger than physical memory, parts of the heap will reside in virtual memory. Because the concurrent collector looks at the heap as one contiguous chunk of memory, the objects allocated and deallocated could reside anywhere in the heap. That some objects will be in virtual memory leads to paging, translation-lookahead-buffer (TLB) misses, and cache-memory misses. Some of these problems are solved by reducing the heap size so that it fits entirely in physical memory, but that still does not eliminate the TLB misses or cache-memory misses, because object references in a large heap may still be very far away from each other. " One other way to solve that is to use locked memory (non-pagable memory). I couldn't believe how fast were my programs when I experimented "Memory+" (a program that can unswap entirely a process in fraction of seconds, but sadly has hiccups that would crash my eclipse JVM). I Tried it with mozilla, lotus notes and also eclipse who is exactly suffering from the same problem (about 150 megs memory). So, if a stranger program can swap in 150 megs in few seconds, I trust mozilla can do it too.
Not sure if this is related, but I have this same problem on OS X with Firefox 0.8 . When I minimize firefox windows, or Hide the whole application, and open it back up (don't even resize window) it back up after few hours, the whole window will be white. The only way around this that I've found was Ctrl+T to create a new tab, than the whole interface gets redrawn and is usable again. After it happens once, it will keep happening each time it is minimized and/or hidden.
WinXP, Moz1.6, with Moz kept in memory and not. Not sure, but this sound so similar that I would offer it up. I use tabbing, keeping 5 or so tabs open. sometimes, one or two tabs use java, and all seem happy for a while, then, it starts clugging, nothing happens for a bit, requests to close seperate navigator windows fail, no buttons work, and then a crash. reminds me of the internal overloads and thrashing of the timeshare days. then, after the reporting requests [once to mozilla and then once to MS], the behemouth closes, usually, the java icon disappears off the XP start bar. What is really odd...is that on -restart- of the browser, my default local home page comes up quickly, but if if i go off to the i-net [example: yahoo.com], the browser causes alot of disk reads [light blinks] [swaping? thrashing?] and for a bit reports "not reponding" in the title bar. If I am patient, 15-20 seconds later, the "not responding" disappears and reports the proper title, and then a few seconds later displays the whole page. it behaves as if some bit of memory, some huge bit, is consumed and not managed well before the crash i describe, and then on the crash, that bit of memory isn't even released. can't exclude that java has something to do with it. but the memory management thing and the disk activity is odd odd.
This problem can be reproduce without the Java application of whatever is out there, so it is safe to say that Java had no part in this.
Please read comment #206. Others already have tried to make this a general and therefore unfixable bug about Mozilla being slow. THIS bug is about a very specific problem that does not occur on e.g. OSX and has nothing to do with Java. Again, just read comment #206.
Not sure if this specific scenario has been reported as well (way to many comments to parse all of them) but here goes... I have been experiencing a similar problem, though not identical. Platform: WinXP (pre-SP1), Moz 1.7b (20040421) (though I think I saw it happen with 1.6 as well) The variation on this that I have been seeing is as follows: I typically have several browser windows open (often each with multiple tabs) at the same time. I also have WinXP forced into "stack common taskbar items mode". When I return to my computer after a prolonged abscense and attempt to restore the 1st (lowest in the restore menu) minimized browser windows it _never_ comes back up, though I am able to restore other browser windows just fine. These other browser windows also come back very quickly. I have tried to access the lost window using the 'Windows' menu but that doesn't work either.
(In reply to comment #343) > Please read comment #206. Others already have tried to make this a general and > therefore unfixable bug about Mozilla being slow. Should a new bug be started for other OSs than? I can easily reproduce very similar problem on OSX on several machines, as do few other people that I know (I think few even mentioned similar problem with OSX on this list). The problem I have is described in comment #340, and it is not related to disk activity (there is close to none), CPU usage (89% idle), or lack of memory (168mb inactive, 138mb free). (all measurements taken right before Firefox was "un-hidden", this is on 1ghz PB G4, 512mb ram). m
(In reply to comment #345) > Should a new bug be started for other OSs than? I can easily reproduce very > similar problem on OSX on several machines, as do few other people that I know > (I think few even mentioned similar problem with OSX on this list). > > In my case, on MacOS X it was not so severe as on Windows XP. Anyway, there can be more than one reason why this happens. However, to me, it is more severe on Windows, I think it should be solved on Windows. Then, something common on both platform should be investigated. Does any one debug it using graphical debugger? I think gdb is very hard to debug with. If there is a performance profiler, then the problem can be more apparent.. but.. I don't think that there is one which can be used for both platforms. (Well... this is why I don't like "printf" or "gdb' only debugging. :( )
*** Bug 244302 has been marked as a duplicate of this bug. ***
Happens for me frequently on a machine with 1GB RAM(!), much of it not in use at the time, WinXP, Athlon 1800+. The config.whatever setting that was patched into Moz 2 months ago may reduce it but definitely doesn't eliminate it on my machine. (Firefox 0.8, according to the site the most recent version and presumably containing the patch.) No way should swapping be the cause of any major slowdown on a machine with 300 *physical* megabytes free, so I'd be inclined to investigate this "touching lots of font files" angle.
derbyshire2@rogers.com: Firefox 0.8 was released on February, 9th, the mentioned patch was checked in at about April, 1st. So as long as you speak about the real Firefox 0.8 build, it does not have this patch. You can always check the build date of your browser in the "About..." menu, for Firefox 0.8 it is "20040206".
Question: Lewis Jardine made a log of the file access by Mozilla 1.5b on 2003-09-24.... If this would be done now with either 1.7 rc2 of 1.8 a1 will this list be different? I'm using 1.8 a1 at work and 1.7 rc2 at home and I still encounter this problem... Shouldn't this (especially with 110 votes) be blocking for 1.7 final? Thomas
(In reply to comment #342) > This problem can be reproduce without the Java application of whatever is out > there, so it is safe to say that Java had no part in this. I think you're too quick to jump the gun and have both misunderstood and probably not even read others' comments. The point that #339 was trying to make was related to the Sun white paper on how to Java can swap several megabytes of memory quickly and the approaches used to speed up that process, and how perhaps Mozilla could learn from that paper. But then, zook, you seem to know everything.
(In reply to comment #349) > derbyshire2@rogers.com: > Firefox 0.8 was released on February, 9th, the mentioned patch was checked in at > about April, 1st. > So as long as you speak about the real Firefox 0.8 build, it does not have this > patch. You can always check the build date of your browser in the "About..." > menu, for Firefox 0.8 it is "20040206". What? Why the hell hasn't the version of Firefox available from the Web site been updated yet since February? That's three months ago! I want a browser that doesn't hang all the bloody time, doesn't cost money (Opera), doesn't contain adware/spyware (Opera again), isn't IE, and works on WinXP, dammit. Also, how do you mung your email against spambots here? Someone else did, but when I tried changing mine to a bogus one there was no way to make the change permanent, and the existing reference to my email didn't change. Is being spammed the cost of posting here then? That sucks. Firefox is the second most common app on my system to show "(Not Responding)" in the title bar; the most frequent perpetrator of that particular Windowsism is of course Explorer. :P
(In reply to comment #352) > > derbyshire2@rogers.com: > What? Why the hell hasn't the version of Firefox available from the Web site > been updated yet since February? That's three months ago! I did not say you cannot get a newer version. You can either get a nightly build that's really up-to-date or you also can get the latest Mozilla Suite release 1.7rc2 which is very stable and has this fix. > I want a browser that [...] Sometimes in life you might not get everything you want. Maybe try Amaya (http://www.w3.org/Amaya/). > Also, how do > you mung your email against spambots here? Get yourself a secondary e-mail address or use Mozilla (Spam filter) for reading mail. But this bug is _clearly_ not the place to ask this. You want to go to a help forum at mozillazine. > Why the hell [...] dammit [...] That sucks. PLEASE READ THE BUGZILLA ETIQUETTE before commenting! http://bugzilla.mozilla.org/page.cgi?id=etiquette.html You are violating pretty much every single point about how to comment! This is also valid for most others of the latest comments. One should point this out in private mail, but since I sent such mail to several people doing nonsense-comments in this bug already just to see someone else will comment the next day, I have to do it publicly to at least try to protect this bug from future spam. Only comment if you have to say something new and useful or else you risk your bugzilla account being disabled! This is not meant to shut up anybody, this is just to try keep this bug "readable" and concise (well, it's somewhat too late for that, but there's still no point in adding even more spam). If your comment is not new and helpful, it's just the wrong place and you should comment in the newsgroups or on mozillazine.org. Thanks.
Whiteboard: [adt2 rtm] [swapped to disk] → [adt2 rtm] [swapped to disk] [READ COMMENT #206 AND #353 (plus the bugzilla etiquette) before commenting]
How about adding that to the summary at the top if possible? Like "swapped to the disk" to make it more eye catching or something 'cause it doesn't look like some folks would think automatically think about it before posting further comments.
This may or may not be related, but these observations may help on figuring out what is happening. I get the long delays [haven't made the pref change, yet.] I notice that the problem is enhanced [more likely or more severe] when there are tabs from diff. domains, each with some java going on. Enhanced when the machine goes hibernating. Oddly, the problem appears on restart of the Moz. app after an application crash, and i have to restart the application. Really odd is that the problem occurs on a machine reboot, followed by a restart of the Moz application. The problem: i have a bookmark/URL with several URL's in a group. [Yahoo.com, my private domain webmail access., etc.] If i open the group on restart or reboot [or sometimes just open -one- page, such as yahoo], the program chugs for a while, with disk accesses...after about 20 secs., the page finally shows. there is no evident network traffic to the i-net. can not understand why i would get this behavior after a appl. crash, -and- reboot of the o.s.
Is there going to be a visible pref for this? Has anyone filed a new bug to discuss whether it should be turned on/off by default, and whether it should be dependant on the amount of installed RAM? Prog.
I think a lot of the problem is explained by comment #59. The lack of code locality (resulting from a lot of modularity) and the need to access a lot of code in order to get anything done (resulting from a lot of code reuse), causes the OS to have to swap pages back in an sequenced order causing disk hits to involve a lot of seeking. The OS would have actually been better off swapping nearly the entire address space back in contiguously instead of reading only a few pages at a time. You might be able to help the Windows VM by hooking both the "minimize" and "defocus" events and remembering what pages make up the currently paged-in "Working Set". Then on either a "restore" or "focus" event use the saved Working Set snapshot to try to sequentially touch all of the originally swapped-in pages to force Windows to read those pages in. Hopefully touching the virtual addresses sequentually will allow Windows to not have to seek around in the swap file as much if we can assume that it wrote the pages out to it nearly sequentially. You can use the QueryWorkingSet() API in PSAPI.DLL to save the list of swapped-in pages http://msdn.microsoft.com/library/default.asp?url=/library/en-us/perfmon/base/queryworkingset.asp To touch the pages in order to force them to be swapped in, you could try just a pointer access within a try-block, or IsBadReadPtr() might be safer (which is basically just an API that wraps a memory access within a try-block for you). Unfortunately I don't see any way you could easily use something like ReadFileScatter() to encourage elevator optimization of more page accesses at once, but you might be able to try touching pages using a small thread pool. When touching the pages, you might try experimenting with touching just the original CODE pages, instead of touching all of the original CODE and DATA pages, to see which performs better. I would suspect that the data gets accessed a little more contiguously by the code and may not need the forced page-in accesses as much. (The bitfields returned by QueryWorkingSet() allows you to tell the code pages from the data pages.)
Depends on: 248423
Firefox 0.9, WinXP 512MoRAM Just want to say that config.trim_on_minimize set to false, don't do anything for me. It's still too much slow, Sometimes it take more than 1min to wake up, and it need an additional 10-15s for each tab. When it happens I usually launch IE, and often kill firefox ... so I'm using it less than I want.
FF0.9 relocates the profile directory. I noticed the startup lag from hell came back after 0.9 upgrade. Uninstalling FF and deleting the old profile directory before reinstalling solved the issue. FF0.9 lag without trim_on_minimize is really bad. At least once you're accustomed to the way it just snaps up with it.
Well, it may be related to virtual memory. One clue monitored by me is that if a P2P program like the Shareaza or the eMule plus is running, the Mozilla Firefox tends to be very slow to switched back to it. In ohter words, it is very slow or the system is very unresponsive when you want to make the Firefox your front-most program. Huh? Is this NEW bug? It has been there fore more than a year!
Comment 358 and comment 359, the Firefox bug is Bug 248423, and the steps given in comment 359 do not actually solve the problem. Comment 360, please read the bug before posting comments that have been posted many times before.
Keywords: conversion
I can definitely confirm that Thunderbird 0.7.1 for Windows obeys the patch. In my case, the slow wakeup was also connected to heavy applications running as well (right now the OpenOffice master document of my diploma thesis takes about 120 megs of physical and 80 megs of virtual ram on my 512 megs Athlon XP 1800+ under Win2kSP4). After a few hours of OpenOffice action, Thunderbird was hard to revive. (In reply to comment #319) > What is the recommended way to activate the patch in Thunderbird? [...] > Of course there's no way to enter "about:config" in it ... or is it? You have to add user_pref("config.trim_on_minimize", false); manually to your prefs.js file. On a Windows PC, a good idea to look for it is at C:\Documents and Settings\[Username]\Application Data\Thunderbird\Profiles\[Profile Name]\prefs.js. (Local versions of Windows may use localized folder names.) If you've moved or created your profile to/at another location, look there. Perhaps you'd just like to search for prefs.js on your local hard-disks. After you've found the correct file: Shutdown all instances of Thunderbird (ie. all open mail windows), open prefs.js with an ASCII editor, ignore the warning "Do not edit this file." and add the above mentioned line anywhere in the file (anywhere insofar as the whole file is going to be re-sorted and rewritten after the next Thunderbird shutdown). Close the file, restart Thunderbird - and this is it. Hope that helps ...
On my machine, the slow startup behavior appears to go away if I use the "Modern" theme instead of the default "Classic" theme. I'm wondering if this is only on my own machine, or if other people can confirm. Before I switched themes, this slow startup behavior happened almost every time after I'd switch back to Mozilla after doing some relatively minor compiles (ie. Debug build for several dozen files) with Microsoft Visual Studio. My configuration: WinXP SP1 933MHz/256MB RAM Mozilla 1.5 downloaded from mozilla.org (without the trim_on_minimize workaround)
This may be related to a similar problem on Mac OS 10.3 with both M1.6 and 1.7: after a sleep mode, a Mozilla function involving a search, such as automatically looking up an email address in the address book, or searching for a URL in Bookmarks Management, M freezes/stalls -- I have to tell OS 10 to quit Mozilla, then reload it. Perhaps if I waited long enough, it would unfreeze -- haven't tried it.
*** Bug 253788 has been marked as a duplicate of this bug. ***
I used process explorer from sysinternals to look at the firefox.exe application I found the following file handles. File C:\WINNT\Fonts\FTBL____.TTF File C:\WINNT\Fonts\bookosbi.ttf File C:\WINNT\Fonts\arial.ttf File C:\WINNT\Fonts\FTBLI___.TTF File C:\WINNT\Fonts\mapsym.ttf File C:\WINNT\Fonts\ariblk.ttf File C:\WINNT\Fonts\symbol.ttf File C:\WINNT\Fonts\georgiaz.ttf File C:\WINNT\Fonts\webdings.ttf File C:\WINNT\Fonts\Arialni.ttf File C:\WINNT\Fonts\verdanab.ttf File C:\WINNT\Fonts\outlook.ttf File C:\WINNT\Fonts\bookosi.ttf File C:\WINNT\Fonts\trebucit.ttf File C:\WINNT\Fonts\georgiai.ttf File C:\WINNT\Fonts\wingding.ttf File C:\WINNT\Fonts\trebucbd.ttf File C:\WINNT\Fonts\FTR_____.TTF File C:\WINNT\Fonts\ftb_____.ttf File C:\WINNT\Fonts\palai.ttf No other application i have on my system has these file handles open even though some of them use many fonts. Could there be some problem with windows locking the files when accessing the font files directly and not through som windows api or swapping them out when not used and thus creating some conflict with windows trying to swap them out of memory and mozilla insisting on having them open.
sure there could be. but we didn't reinvent font handling on windows. that's something we only did for unixes. if you want to chase this ghost, close the file handles w/ process explorer and see how mozilla behaves.
*** Bug 258774 has been marked as a duplicate of this bug. ***
*** Bug 259123 has been marked as a duplicate of this bug. ***
Hello Everytime I open firefox 1.0pr on my laptop after hibernation it causes a diskswap for around 30sec while firefox is compleatly unresponsive. My machine is a Pm 1,6 512 ram and lots of free diskspace. I seen this behaviour since I got this computer last christmas. Long time inactivity also causes this behaviour I think but hibernation makes it 100% reproducable. I don't need to have any tabs with websites open or other open programs to trigger it. Other people in this bug comments has also talked about hibernation trigger it for them. I know my comment does not add any new info but I want to tell you that there is still an issue here and it has been for a loooong time. This is the only thing that I dislike with firefox and I would love to see a fix, workaround or even help you diagnose the problem if you tell me what to do :)
read comment #277
comment #277 is a half fix at best. Still glad to have it, but it meerly postpones the inevitable. Firefox/Mozilla will still slip into a deep sleep and give you the same problem. Blame it on windows if you want, but it keeps many corporations (including ours) from using it. You can NOT keep it minimized until you need it. It's quicker to kill it and restart (though loosing any web pages you might have had up)
I know for sure many USERS won't touch Mozilla/FF/TB if it takes 1-3 minutes for the damn thing to come up from idle. Quick fix would be to put a checkbox for this in the OPTIONS. And dare I say, default to NOT swap out FF/Mozilla/TB at minimize. Considering how badly broken the implementation is ATM, that's only reasonable. Plus, that'd provide nice wide-audience test to root out any possible side-effects.
It would be interesting to see if the patch helps the hibernating case in comment #370. I was skeptical at first, because I thought hibernation might have went through and minimized all the working sets of the processes before hibernating, but I ran a quick test on Win XP and it doesn't so it could very well help. As mentioned it's not a complete solution and has its drawbacks, but until someone has the time and go through and address the real problem this will hopefully give those affected some relief.
(In reply to comment #374) Hello. Yes it works quite well, it still swaps but only 3-5 seconds, not 30-50 :) What is the drawback you talked about with this then?
The drawback is that when the browser is minimized, that memory is marked as available. Say you have apps A and B up and running with Mozilla. Now you minimize Mozilla. And now you're working with A and it needs more memory. Normally the memory would come from Mozilla, assuming available memory was sufficiently low, since it's minimized and the working set has been shrunk. Now that is not happening, app B stands a chance of having its working set size reduced. The goal of the way Windows was designed is that app B is assumed to be active as it wasn't minimized and stealing memory from it would be undesirable. A lot hinges on your usage pattern of the software on your system. I'm sure this change works well some, but I'm unconvinced its a good change for all.
Either I'm crazy or the "fix" makes other programs crawl on startup.. In fact exactly like mozilla family does unpatched. Anyone else seeing this?
That's exactly the drawback of this fix. For some users, who the browser is the primary app and only occasionally run other memory hungry apps it's a win.
Oh no. Not memory hungry at all. Memory usage has never been much of an issue, really. You can have 100-200MB of free physical RAM and still get hit bad. Mozilla code is doing something really retarded, that's all.
Memory IS the issue. If you're going to debate this, please read this entire bug. Yes I know that's no small feat. But making comments without knowing the history, just makes this bug that much longer and adds no value. In short don't blindly believe what Task Manager is telling you. Avail memory includes memory used by the disk cache.
Hi again. Yes I can feel the impact of this in other apps for sure now, at first I thougt it was coincidences but after a while, firefox makes something as simple as navigating the start menu hung and swap for one or two seconds for each new level I expand, even when my system sais I have 344mb free physical memory. Not a normal behaviour for sure. I think I'm going back to the default setting for config.trim_on_minimize and close firefox instead when I hibernating :( It's really sad to have this annoying and unexplainable behaviour on a otherwise so damn good pice of software :( Isn't there some VM gurus that can debug firefox to find out whats happening? I mean, this can't be a dead end that can't be fixed without rewriting large pices of code, can it? Good luck
How do you apply the "patch" ??
(In reply to comment #382) > How do you apply the "patch" ?? read #c277
*** Bug 262814 has been marked as a duplicate of this bug. ***
This is an experimental patch that implements what I suggested in comment #357 to use QueryWorkingSet() to "remember" what pages were physically swapped into its address space whenever a window is minimized. This is useful for people who use Mozilla, then minimize it to use some other memory-intensive applications for awhile, and then try to resume using Mozilla. When Mozilla is unminimized, it walks through its last copy of the working set and touches just those pages in order to force them all into memory again. This patch modifies just the code in the "bin\components\gkwidget.dll" file, and adds a new configuration parameter "config.restore_saved_workingset" which defaults to true. As a test, I did the following: 1) booted a Windows 2000 computer with "/MAXMEM=256" in the c:\boot.ini to limit its RAM to 256MB. 2) Load up Mozilla with 7 tabs each displaying a 1400KB size complex HTML page. Mozilla's working set size for all of these large pages was about 131,472KB (total virtual address size about 126,712KB). 3) Minimize Mozilla and its working set shrinks to about 1,308KB (since my "config.trim_on_minimize" was left unaltered). Now run several instances of "LeakyApp.exe" (comes with NT Resource Kit for stress testing) to force all of the old working set pages to be discarded so that Windows will be forced to read any swapped pages back from disk. Stop and exit all LeakyApps once all RAM has been allocated and the system is having to rely on swap space. Mozilla working set is still using about the same ~900KB-1300KB. 4) Now try to restore the minimized Mozilla window and measure how long it takes until you are able to scroll around in a tab, change to the next tab and scroll in a second tab. With my patch, it takes about 16 seconds for Mozilla to restore itself, but after that I am able to immediately scroll around in all tabs immediately without any delay. Repainting and UI responsiveness was immediate once the window was visible again (window does not redisplay until after the 16 seconds). The working set size reported by Task Manager is nearly equal to what it was before I minimized the window, confirming that everything was swapped back in. (Here is sample debug output from DbgView, showing timing metrics. The 16 seconds to restore is during 187.93540464 - 171.88102315). 0.00000000 [1680] gRestoreSavedWorkingSet is saving the current working set 0.06058116 [1680] gRestoreSavedWorkingSet is done saving 171.88102315 [1680] gRestoreSavedWorkingSet is restoring the original working set 172.03149702 [1680] There are currently 315 pages (1260 KB) present. 187.92604730 [1680] Forced 35100 pages (140400 KB) to become present. 187.93540464 [1680] gRestoreSavedWorkingSet is done restoring 212.79026217 [1680] gRestoreSavedWorkingSet is saving the current working set 212.89532804 [1680] gRestoreSavedWorkingSet is done saving Without my patch (or with it and "config.restore_saved_workingset" set to false), Mozilla takes about 23 seconds to restore and allow me to scroll in *JUST* the first tab. Repainting is slow and staggered as the OS tries to piecemeal swap-in the complex data structures and dozens of supporting DLLs as they are referenced. Restored working set size is only about 15,100KB after the 23 seconds (the memory associated with just one tab), and clicking on any of the other tabs requires more swapping in and further delays and sluggishness. My patch is very unpolished and still has diagnostic OutputDebugString() calls in it that I was using for timing measurements. Also I added a DLL dependency to PSAPI.DLL, but it will likely need to be a delay-loaded or manual GetProcAddress() invocation in any final version, since that DLL will not be present on downlevel Win9x platforms. Also maybe the workingset save/restore might want to be made to occur on focus/defocus events also, instead of just minimize/restore. The disadvantage of touching all pages in sequence is that the OS loses track of the original last-access timestamps on all of the pages, meaning that it will not be able to intelligently select which few pages it should swap out if it really does need to reclaim some more RAM pages for another purpose. Note that you must exit and restart Mozilla if you use "about:config" to change the "config.restore_saved_workingset" setting for it to take effect.
Here is one other trick that may be done for further reducing the perceived 16 second restoration time for the full 131MB that I mentioned in comment #385: Create a second thread to do the page touching, so that the window thread will not be blocked. That would mean that Mozilla will try to resume running (and start piecemeal paging things in by itself too), in competition with my page touching which increase the total time slightly. However, the window threads and Mozilla may be able to become fully responsive more quickly since not all of that total working set is absolutely needed immediately. As my example demonstrated, only about 15MB of the 131MB is minimally needed for the getting just the first tab up. It would be even more optimal if my page touching would use heuristics to try to first touch the more important pages that make up that 15MB, and then continue to touch the entire 131MB in the background thread. If Mozilla used separate heaps to keep related sets of data contiguous in memory, then maybe that might be a method for deciding which address regions/pages to touch at the same time.
Interesting, I wouldn't have expected that much improvement, but I guess as you pointed out, it gets a boost from sequentially running the original working set pages, possibly in order. It will be interesting to see if other people see the same benefit. And thanks for taking the time to try this out and provide a patch.
I appreciate Jeff's efforts to create a patch, but from what I can understand (I'm not a programmer) this is an interim fix at best. What will it take to get a long-term fix? I've read where some people have said that it won't be fixed in v1.0. Will it take a real overhaul in the way Firefox works? I ask this with tremendous appreciation for what all of the volunteers have created, but with great concern that I'll soon lose patience and have to go back to IE. FYI, I've set config.trim_on_minimize to false, and that helped for a while, but now it still takes a couple of minutes for my laptop to awaken after being in suspend mode, at least when it hasn't been shut down in several days.
Right it's not a solution but it might reduce the pain until a real solution is finished. What will it take? It's going to take a lot of time and effort on both the final investigation and implementation, assuming what I've stated is the problem. And I think we're seeing this problem agrivated on some systems more than others. For all the systems I've had Mozilla has paused when restored, but no worse than other memory hungry applications. That's created a lot of noise for this as well, making it difficult to find the real source of the problem.
Any chance of getting a binary with the patch? I can't build my own binaries but I've had this problem since #126 so I'd be interested to test it. I'd especially like to see how this fix affects the REAL problem as I see it. For me mozilla regularly takes forever to come responsive in low-memory-usage (commit charge <1/3 of RAM), high-available RAM (1GB) environment after being minimized/idle for extended time (30min - couple of hours). Config.trim-on-minimize patch mitigates that but seems to affect the performance of other apps.
You can try http://www.bovine.net/~jlawson/exchange/moz76831/mozilla-bin.zip that I built using Visual C++ .NET 2003, so you will need to find a copy of MSVCR71.DLL from somewhere and put it into your system directory if you don't have it already. BTW, the thread suggestion that I made in comment #386 seems to indeed make things much worse since Mozilla and my other thread are now both fighting to swap pages in at the same time.
I was afraid the thread might take you back to square one. I think you're getting your boost by pulling in sequential pages, and the thread running async eliminates the sequential part.
I did some testing with the binary. After working with Word & doing light image manipulating for about 2 hours, mozilla took very long time to pop back up. Something on the order of 1 minute. Mozilla didn't draw anything on-screen after I clicked on the mozilla-box on the bottom of the screen. I assumed it had crashed and/or was drawn outside desktop. I had time to fire up windows help and go looking for the keyboard shortcut for moving windows.. The TAB in the bottom of the screen turned blue instantly, thought. Firefox I ran for comparison (with config.trim_on_minimize = true) came up much faster (5-10 secs?). Interestingly enough, when mozilla finally popped up, it was instantly responsive. And the window came up fully drawn, etc. None of the usual gray window slowly filling up-nonsense. Firefox on the other hand was rather sluggish getting the visible tab resposive. Switching to the other tabs was sluggish as well.
Yes, the lack of any visual indication during the long swap-in period is indeed a little suboptimal (perhaps the cursor can be made into to an hourglass or something), but the full responsiveness of Mozilla once it is done is the reward. My binary should allow you to combine config.trim_on_minimize = true with config.restore_saved_workingset = true, if you also want to prevent Mozilla from immediately shrinking its working set when you minimize. That may reduce the chance of the OS fully swapping Mozilla out by the time you try to return to it. However restore_saved_workingset will still have to block on restore if there are a lot of pages that need to be swapped back in.
Actually, "true" is the default behavior for trimming. If you want Mozilla family to hang on memory, you need to set it "false" .. But that appears to lead into issues with other apps. The paging in performance was less than stellar. ca. 1 minute is EXTREMELY long time to swap in an app with a VM size of ~50MB. There is apparently something (still) very wrong with the way mozilla handles memory under Win32. Perhaps it'd be possible for mozilla to use bigger pages? Would it be possible to track the page-in process, millisecond wise? Perhaps the page-in happens reasonably fast but something else (like the fonts?) hold things up forever?
You can use Performance monitor to graph page faults for an application. You might also check system events to see if maybe you're getting disk read/write problems. I've yet to see it take a minute to swap in and be responsive and I'm now playing with a 600+ meg guerilla app with Mozilla and Firefox in the background and only have 512 megs of RAM.
I believe Olli's comment above is the real issue here: how is it possible that paging in the browser takes MINUTES (up to 15 minutes in my experience) instead of SECONDS? How is this paging triggered from the browser? Is it one single call to a Windows API? Is it something more complex? Is the browser doing something else while paging in the memory? Furthermore, if this performance is what should be expected in WinXX, then why do other big applications not show the same poor performance? I think this to be the real issue to focus on.
I created attachments with perfmon graphs for Mozilla and Winword. Winword has a 10MB document open with large images (which I'm actually working on) .. Mozilla has 4 tabs open. Winword has only working set equal to the doc size (10MB) but whopping 666MB of virtual bytes. Also 666 file handles (I'm not making this up..) Mozilla has at the moment ca. 60MB working set, about 100MB virtual bytes and interestingly enough, 250 file handles. You can see from the graphs that mozilla takes about 30 secs to come up, while Winword can make do with about 4 seconds. OK, mozilla working set is about 5x more than with winword.
Jeff, have you tried timing the iterations of the page-touching loop? I just wonder if there are large differences.
For what it's worth, I've been comparing FF and the patched Mozilla head-to-head with same tabsets open. Both have trim_on_minimize enabled. FF is MUCH faster coming up (about 4-5 seconds /tab) than Mozilla with the patch. I just had to wait 1 minute for mozilla to come up and I have the performance monitor graph to prove it. Even refreshing all 4 tabs of FF is much snappier than waiting for mozilla. By the way, is 200 page faults/sec a lot or a little? Because that's the level mozilla stays in for about 30 secs and then it has higher peaks (50-80) during the latter half of waking up.
Another image with both FF and Mozilla. Cut & Pasted image, I didn't have them coming up at the same time. Firefox was asked to open a jpg image, you can see the big spike in IO when it finally wakes up (after about 68 seconds, I grid = 4 secs) .. Up until that point, low pagefault activity, 50-70 hits /sec, no I/O activity. For Mozilla, taskbar icon was just clicked on. You can see how it takes about 30 seconds before the page-in process really kicks in, until that point it's low pagefault activity of some 100 faults/sec. Is that low? Or really high?
*** Bug 268341 has been marked as a duplicate of this bug. ***
(In reply to comment #389) How can I (non-programmer) help with the investigation so that someone can fix this problem? (BTW, I'm not the Doug who was commenting on this thread in 2002.) And how do I apply Jeff's patch? Should I?
Any chance of getting a build which will log how much time is spent on which module? It's been three and half years and we still don't even know which module causes the laggy behavior.. I suppose that to get a meaningful log you'd have to keep on logging until the pagefault activity dies down. Just to avoid farce like in comment #94.. If Mozilla/FF/TB only took 8 seconds to come up I'd have nothing to complain about!
Product: Core → Mozilla Application Suite
Can anyone venture an educated guess as to whether this bug affects Thunderbird? I know that all of these applications share some Mozilla code, and that nobody knows for sure where the guilty code is. I installed Thunderbird 0.9 a few days ago and haven't had the problem, but it could be that I haven't driven it hard enough yet.
Thunderbird definitely has the problem, too.
*** Bug 273012 has been marked as a duplicate of this bug. ***
-> Core since this hits the Suite, Firefox, and Thunderbird
Component: XP Apps → XP Toolkit/Widgets
OS: Windows NT → Windows XP
Product: Mozilla Application Suite → Core
One problem. This bug report was originally filed from a reporter with a Windows NT O/S.
(In reply to comment #410) > One problem. This bug report was originally filed from a reporter with a > Windows NT O/S. Yes, but we usually use WinXP when it hits all versions of Windows, which this does.
rparenton@louisianaada.org: absolutely not. i'm not sure who your royal we is, but you should be using the *oldest* os that experiences the problem, not the newest.
(In reply to comment #412) > rparenton@louisianaada.org: absolutely not. i'm not sure who your royal we is, > but you should be using the *oldest* os that experiences the problem, not the > newest. By "we", I meant the community, as I could have sworn I was told the other way around (newest vs. oldest) by a dev in the past, but I stand corrected. OS -> NT Sorry for the past few bugspam emails all this has caused.
OS: Windows XP → Windows NT
This 'bug' has become a real pain for me. Running XP Pro at home, never a problem, very snappy. Then I installed 1.8a4. Almost immediate dragginess. Nothing extraordinarily severe, say 10 or 20 seconds for full functionality to be restored. My notebook, win2k. Awful, just awful. Sometimes as much as 2 minutes to come to life. Has been this way for probably at least a year, huge amounts of disk thrashing. Went all the way to 1.8a5 on it and it made no difference. So I try 1.7.5 on it. Just installed on top of existing app. Notebook is now totally devoid of this bug, it is quick and restores INSTANTLY, even coming out of sleep mode. Back to the desktop, put 1.7.5 on top of 1.8a4 and no difference. Still mild delays. So I close all moz instances, zip up all moz files (no cache files), delete them all, install 1.7.5 (no uninstall done) and copy back old moz files, it is now much much better, not wuite perfect - maybe 5 seconds to revive, but much better. config.trim_on_minimize has been false on both boxes for some time now.
I wonder if fragmentation is coming into play for you. It be interesting to run a fragmentation report and see what comes back.
it would also be interesting to compare the number of fonts you have installed on each machine, as that is speculated to play a big part in this bug.
The Fonts control panel applet reports 350 on the XP box and 186 on the win2k one. Disk defragmenting has been done in the past, especially attentively on the notebook. I had very thoroughly defragged the notebook, even re-installed windows (on top) and also got a pagefile defragger, all to no avail.
*** Bug 277531 has been marked as a duplicate of this bug. ***
*** Bug 271014 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
I have noticed that the problem is significantly worse when I leave Microsoft Money running. Money 2002 Standard OEM Edition version 10.0.
Discovered one more method with the disk swapping issues where I found the difference is more noticeable with the tabs. Let's say you have 4 tabs open with webpages then after a few days of some disk activities, those 4 tabs become sluggish regardless of WHETHER it's minimize or not. Then I opened a few more new tabs for use. Those new tabs are noticeably to be frequently quick in the long run when they are active while switching back to the old tabs would then make the browser become slow/sluggish. Hope this will help you find more ways to identify the culprit of this bug.
*** Bug 285970 has been marked as a duplicate of this bug. ***
The Netscape v8.0 Beta doesn't seem to suffer from this problem. As it is based on FireFox 1.0, it seems that the folks at Netscape have solved the problem. Is it possible to find out how they did it?
(In reply to comment #423) > The Netscape v8.0 Beta doesn't seem to suffer from this problem. As it is based > on FireFox 1.0, it seems that the folks at Netscape have solved the problem. Is > it possible to find out how they did it? My guess is they are using the startup code from the software formerly known as Mozilla Suite. This is yet another advantage of that software.
(In reply to comment #424) > My guess is they are using the startup code from the software formerly known as > Mozilla Suite. This is yet another advantage of that software. No. Check out early messages for comments on "quick launch" which makes the problem much worse. Longer you have mozilla/firefox/thunderbird sitting idle, the slower the startup. And with quick launch, it can be idling overnight etc etc.
(In reply to comment #425) > (In reply to comment #424) > > My guess is they are using the startup code from the software formerly known as > > Mozilla Suite. This is yet another advantage of that software. > > No. Check out early messages for comments on "quick launch" which makes the > problem much worse. Longer you have mozilla/firefox/thunderbird sitting idle, > the slower the startup. And with quick launch, it can be idling overnight etc etc. > Heck, you're right. I can't believe this problem goes all the way back to 2001. Is it a memory thing, then? If so, shouldn't it have the mlk keyword?
It's not due to a leak, though leaks agrivate the situation. There's a number of things at play here. Amount of memory in use, GC algorithm, possibly the way we allocate memory, and a few UI related things that aren't my forte. Most all are very hard to deal with in a mature application like this. Other things that will magnify this problem on an individual user's machine is page file fragmentation and having your page file on a slow disk as well as having other large applications running or applications accessing a lot of file data while the browser is minimized.
(In reply to comment #427) > Other things that will magnify this problem on an individual user's machine is > page file fragmentation and having your page file on a slow disk as well as > having other large applications running or applications accessing a lot of file > data while the browser is minimized. That's a dead horse thoroughly kicked, no? If you compare how Winword comes active with a big document open (https://bugzilla.mozilla.org/show_bug.cgi?id=76831#c399) compared to Mozilla/FF asked to open a jpg image (https://bugzilla.mozilla.org/show_bug.cgi?id=76831#c402) there's quite a big discrepancy. Mozilla/FF basically sits doing NOTHING for 60+ seconds before it "wakes up" and swaps itself back in fairly quickly. And this is a problem that was there for 0.8-0.9 work in progress mozilla suite! I quess if you ignore a problem long enough it'll "mature"..
Dead horse yes, but it's still part of the problem. When Mozilla is restored, often the GC is going to run. The mark phase will touch every JS objects and many XPCOM objects via XPConnect. The objects are not clusters so page hits are random. The one patch that touches memory sequentially when Moz is restore helps in some cases. WinWord is most likely currently not developed in a GC based language. When you restore WinWord you won't see the entire workingset pulled back in memory. What you'll see is smaller set because there's no GC that occurs and only the currently viewed part of the document is touched and needed in memory. I've used other large Java and .Net based apps and they all suffer the same problem from GC and exhibit the similar behavior of Mozzila. The generational algorithms help but it's still an issue when there is memory pressure. Moz doesn't currently have a generational algorithm, its a simple mark/sweep routine. As I said that's just one element. There are probably other issues and may be specific to graphic cards and users systems. I've only been witness to the delay do to GC kicking in, so that's what I've focused on. It's real, and it's a problem, but that doesn't mean it's the only issue.
Windows 2000 Pro; 1.3GHz P3; 256MB RAM; Mozilla 1.7.5 My goodness what a long thread to read through. I must say I am impressed by the civility of it, and the good spelling and grammar. A few people seemed to get a little hot at times, but they never seemed to burst into flame. I've been using Mozilla for a year or two now. At first I continued to use Windows for most of my browsing but as Mozilla improved, and attacks on Windows vulnerabilities increased, I used Mozilla more and more, and now I only use Windows when I have to reply to my yahoo e-mail. (Yahoo mail only does plain text in Mozilla.) (I just joined this discussion. This is the first time I've posted. I don't know whether my e-mail address will show up. I hope not or I'll surely get a lot more spam in my yahoo mailbox.) I have noticed occasional peculiar behavior when maximizing Mozilla after it sat minimized for a while, but it has never taken more than a few seconds to completely restore. At least, as far as I can recall. I didn't even realize that the problem might be with Mozilla until I stumbled onto this thread. I'd like to contribute. I hope this helps. I don't use tabs, but minimize pages and applications to the bottom bar, I forget what it's called (system tray?) I often have 10 or more things minimized to it. I have gone for months Hibernating my computer every night so as not to lose them. One thing my computer does that hasn't been mentioned in this thread is sometimes the light which indicates hard drive activity comes on for a while and whatever application I have running at the time slows way down or stops until it's finished whatever it's doing. I don't think it's because I'm running out of RAM because I rarely use programs which use a lot of RAM. I can't recall for certain but it may only happen when I have a Mozilla page (or many pages) minimized.
I'd like to suggest both the priority and severity of this bug be increased, for two reasons: 1. It's been hovering around since 2001, apparently, the current priority / severity having not fostered its resolution, and 2. More importantly, it's a usage-killer on the "modern" Windows OSes, by which I mean that people who try it will just go back to IE once they experience the problem. Whenever Firefox (or whatever pieces thereof) swaps out on my WinXPPro laptop, it takes 30 seconds for Mozilla to reload. During this time, the hard disk light is flashing, and the machine is for all intents and purposes dead to the world (i.e., other apps become extremely slow). Then, for virtually any "button" pressed in Firefox, there is another 10-20 seconds of hard drive thrashing, whereupon Firefox appears fully restored. My only workaround is to close Firefox completely and open a new session. That process is much faster than reloading from swap, but of course I lose any tabs, have to relogin to sites like Yahoo Mail, etc. Thanks and regards, Chris
It's unbelievable that there's been no action on this bug. I guess it's asking too much of the Assignee or QA Contact to escalate this problem to someone who would/could actually fix it, or even give a **** about it... Anyway, I found a workaround, and would like others to confirm. If, instead of minimizing Firefox, you simply resize the window to something tiny and out of the way, you can then maximize it and continue right where you left off! This works for me even when I suspend or hibernate my XP laptop. Given this behavior is confirmed, it shows how aggressive Windows is at swapping minimized apps to disk, even if there's enough memory to just leave the app alone. Of course, the drawback is you have Firefox occupying your entire screen, but to me it's a godsend to just double-click the title bar to toggle from tiny to giant, rather than wait 1-2 minutes to restore or kill a swapped Firefox session! Regards, Chris
Assignee: jag → cniggeler
QA Contact: pawyskoczka → cniggeler
Assignee: cniggeler → jag
QA Contact: cniggeler → jrgmorrison
Chris, Are you sure you're testing it 'properly'? It shouldn't matter whether or not Firefox/Mozilla is minimized per se, just whether or not it's been swapped to disk. This happens more quickly when it's minimized, but it can happen when it's still displayed, too, if there's a lot of memory usage elsewhere.
No longer blocks: majorbugs
I'm taking this bug, and I propose to fix it by telling the OS that we want to keep all of our VM while iconified. Don't spam this bug again, or you will be sorry. /be
Assignee: jag → brendan
Flags: blocking1.8b3+
Target Milestone: --- → mozilla1.8beta3
(In reply to comment #434) > I'm taking this bug, and I propose to fix it by telling the OS that we want to > keep all of our VM while iconified. s/iconified/inactive/ -- IOW, we will tell the OS we need as much VM as we are currently using, minimized against a sanity-check maximum value that I will make up based on some samples taken of long-running Firefox instances around the office (feel free to mail me your samples, or an average and a maximum). /be
Appreciate the direct approach on what might be the definitive cure. I've read thru the discussion, and the question I have is, "Until the cure is ready, why can't the config.trim_on_minimize workaround (Comment 277) be included and set in the official Firefox releases?" After all, it has been available for over a year (since Mozilla 1.7 RC1) and comment after comment suggested (begged for) exactly this, starting March 2004. I understand the concern that it doesn't identify or resolve the root problem, but after years and years, surely we could agree that an interim step that works is better than nothing?! I've been testing this workaround for 3 weeks since its suggestion to me by Phillip Stewart (thanks!). I can report that it works and that I have encountered _no_ system or performance issues. If the pref were set in the releases, would-be IE converts won't encounter the agonizingly slow restore problem. With the end-user severity I believe this is, I feel it would take a LOT for the workaround to be worse than the ill it is addressing! One non-technical question: what is the "spamming" that Brendan referred to (Comment 434)? Maybe we all are being subjected to it, and I don't notice because I generally just empty my 200-entry Yahoo Spam box. If it's in reference to my recent entries, I reply: This bug has such a rich history that it now spans 53 single-spaced pages - enough for a novella or a TV movie script ;-) But surely that's not the fault of 150 people interested enough to press for progress/resolution of a bug that just "celebrated" its 4th birthday, is it? Thanks and regards, Chris
Flags: blocking1.4b-
Flags: blocking1.4a-
Flags: blocking1.4-
Minusing for 1.8b3 per Deer Park meeting. Still looking for magic here to satisfy most parties before we consider blocking a release on this.
Flags: blocking1.8b3+ → blocking1.8b3-
Flags: blocking1.8b4?
Attached patch fix — — Splinter Review
Obvious fix. /be
Attachment #186265 - Flags: superreview?(jst)
Attachment #186265 - Flags: review?(pavlov)
Attachment #186265 - Flags: review?(pavlov) → review+
Comment on attachment 186265 [details] [diff] [review] fix sr=jst :)
Attachment #186265 - Flags: superreview?(jst) → superreview+
is this bug going to remain open after that patch is checked in? it seems much more like a workaround than a fix. the real problem is that mozilla pages in much more slowly than any other app, and this will still occur with the patch if you force mozilla to be paged out by using other apps. note that i'm not volunteering to fix this bug as i wouldn't know where to start, i just think that the bug should remain open as long as the issue is still an issue.
Comment on attachment 186265 [details] [diff] [review] fix This will fix the complained-about symptom, without causing other problems, according to testimony of people who have defined the pref set to 0. On Windows, it does not pay to be "nice". /be
Attachment #186265 - Flags: approval1.8b3+
Fixed. Do *not* reopen this bug or I will start tattooing it on you. It has lived way too long, is full of noise, has far too many cc: list member, and is too broad to be useful (that is, "fixable" beyond what I'm doing today). Comment 440 talks about "mozilla" paging too much (when config.trim_on_minimize defaults to 1, until today; or if you are foolish enough to set that pref to 1 after today). If you have a problem with the application suite, file a new bug in that bugzilla Product. Do not file a Core bug. Bugs exist to be fixed, not to live forever asking someone to "end world hunger" or "ensure world peace". Mozilla or another Gecko-based app may page a lot in some cases, but not because it's being restored after a minimize on Windows, thanks to this fix. If Windows doesn't page efficiently in cases that other OSes handle better, write Microsoft. Again, file new bugs for new problems in particular apps or products. Thank you, drive through! /be
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Flags: blocking1.8b4?
Flags: blocking-aviary1.1?
I nearly jumped out of my seat when I saw this bug was fixed, unfortunately I see its more of a workaround, but I guess its better than nothing.
You kibbitzers should take it to a new bug if you have *actual evidence* of a separate issue (such as the font handle leak, or bloat, or whatever problem might be hidden amid all the noise here; thanks to mailto:scratch_is@despammed.com for trying to bring it to light in email, but it's never wrong to file a new bug on a new problem). The claim that our no longer giving bad advice to Windows, which other big apps do not make the mistake of giving, is a "workaround" and not a "real fix", makes me want to reassign this bug to the last commenter. Have you so little clue or so much need to posture that you *must* such a useless comment to this bug's carcass? Try to do something useful in bugzilla, or don't comment at all. /be
FF's default does the right thing by trimming. Disabling trimming is a workaround. (Other apps tested which trim successfully using >200MB; Protel DXP, Quark6). The bug however is not in "to trim or not to trim" - the root cause of this bug is in the sheer pm/vm consumption (over time). I don't think anyone would really believe refusing to trim is anything other than a workaround for avoiding the delay incurred when swapping back in pages from disk-based vm. *Any* app asked to page back in 200MB from vm is going to chug. So this bug is not a bug, it's a symptom of a different bug. A lot of different bugs. Some are fixed, some unfixed, and some remain unidentified. Spend some time thinking about why this bug exists, and you'll understand why the only fix for this bug lies in the resolution of other bug(s). Proof? Start here:263930,249469,131456,288167,283063,130157,120712,158317,261920,251380,294452 (look for dupes of these bugs and comprehend how big the problem is - and then think how much hard work is needed to solve it). Only when FF's mem consumption (and its failure to release) is solved will this bug be properly fixed. Until then, let's take trim=0 and treat it as a fix for this bug - and continue to work on the root causes. Thanks for your hard work devs - some people don't know how much hard work goes into the Mozilla family. The rest of us: our job is to file accurate bugs, with clear steps to reproduce. And try to recognize that a bug may just be a symptom of another bug, identified or not.
*** Bug 298979 has been marked as a duplicate of this bug. ***
*** Bug 299202 has been marked as a duplicate of this bug. ***
Depends on: 300689
Blocks: 300689
No longer depends on: 300689
*** Bug 311810 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: