Closed Bug 76831 Opened 23 years ago Closed 19 years ago

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

Categories

(Core :: XUL, defect, P4)

x86
Windows NT
defect

Tracking

()

RESOLVED FIXED
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)

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: nsbeta1nsbeta1+
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 patchSplinter 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.0mozilla1.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 fixSplinter 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.