299578 - very slow restore from minimize after memory growth compared to other applications

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[scratch]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050531 Firefox/1.0+

the fix to bug 76831 helped to cover up the slow paging of gecko apps by causing
them to get paged out less frequently.  the paging problem still exists, though,
and should really be addressed.  i've come up with a reproducable testcase to
demonstrate this problem without setting config.trim_on_minimize back to true.

Reproducible: Always

Steps to Reproduce:
1. use firefox for a few hours, open new windows and tabs, get the memory usage
at or above 100 MB
2. open a few large images in photoshop (or most likely the gimp, or anything
else that will also use around 100 MB of memory)
3. minimize both apps and leave the computer on overnight
4. restore both apps

Actual Results:  
photoshop becomes completely usable after 10 to 15 seconds.  firefox takes about
60 seconds to get about as usable as it's going to be, and still has a noticable
feedback lag compared to a fresh start.

Expected Results:  
firefox becomes completely usable after 10 to 15 seconds, just like photoshop.

not being very familiar with the mozilla codebase myself, i find the excessive
font handles mentioned in comments to bug 76831 very suspicious sounding.

Comment 1

[Jaime Mitchell (use [e-mail] for email)]

The fix for bug 76831 was not checked in until 2005-06-14 thus your build from
20050531 does not contain this patch.

Please up date your build to a current trunk nightly. You should always use an
upto date build (preferably todays build) before filling bugs.

Please mark this invalid if todays build does not exhibit the same symptons.

Comment 2

[scratch]

the patch to 76831 simply changes config.trim_on_minimize to false by default. 
this is a setting i changed manually in about:config the day it became
available, so installing a newer build won't change anything.  however, if you
truly would see the bug as more valid with a new build, i'll reconfirm with a
new build.  i've talked this issue over with brendan via private email and he
suggested i file the bug.

Comment 3

[Jaime Mitchell (use [e-mail] for email)]

(In reply to comment #2)
> the patch to 76831 simply changes config.trim_on_minimize to false by default. 
> this is a setting i changed manually in about:config the day it became
> available, so installing a newer build won't change anything.  however, if you
> truly would see the bug as more valid with a new build, i'll reconfirm with a
> new build.  i've talked this issue over with brendan via private email and he
> suggested i file the bug.

Sorry didn't realise that. Please disregard comment 1.

Comment 4

[Brendan Eich [:brendan]]

Olli: I am glad you filed this, but (especially after you wrote in email to me
that the issue is not obviously VM paging: 'there's the lack of HDD trashing
during the long delay") why did you put "paging" in the summary?  I'm changing
it to describe the symptom only, not jump to conclusions.

Confirming for Olli.

Olli, anyone: is minimizing to iconified-in-system-tray a requires step?  That
is, if you do everything but step 3, and change step 4 to simply resume using
both apps, do you see the same unusual delay?

/be

Comment 5

[scratch]

brendan: i'm the reporter and i'm not sure who olli is, perhaps you were
discussing this with someone else as well? (our emails were a few weeks back, i
got a bit busy with real life and didn't get around to filing the bug until now)
 i didn't notice any thrashing (though i wasn't paying close attention) but i
suppose i'll repeat the trial tonight without minimizing and try to pay
attention for any thrashing.

Comment 6

[Brendan Eich [:brendan]]

Oh, sorry -- yes, I was corresponding with Olli Mannisto over this symptom (or
the one just like it ;-) recently too, and I thought he was the reporter of this
bug. I've cc'd him, so we should be able to figure out whether this is the bug
we can all use to make progress on one symptom, or whether there are two
symptoms better tracked with two bugs.

/be

Comment 7

[Boris Zbarsky [:bzbarsky]]

Brendan, this is a Windows-only issue as far as I've been able to determine, so
I really have no idea where to even start on this one....

Comment 8

[scratch]

results from last night's test were that both apps responded immediately to
continuation of use this morning.  however, considering i have 512MB of memory,
they probably were both still in physical memory.  again, no thrashing, but
that's absolutely to be expected considering what i just said.  anyone have a
low memory machine handy to try to force firefox to be paged without minimizing it?

Comment 9

[Olli Männistö]

Gentlemen, 
Real life is a problem over here as well, I haven't had time/energy for many
"extra-curriculum" activities I'd hope. 

Here are my comments from email reproduced in full:
"The delay on restoring a gecko app is just as bad regardless of small/big
memory footprint. Available RAM does not affect it either. It's not a paging
performance thing.

There is, one more time, no HDD churning during the long delay waiting for
gecko. And the system runs just fine on the meantime.

I saw some "paging performance" on this box just now as I had a dozen of big PDF
files open in acrobat etc. HDD light comes up and the whole system becomes
sluggish. Quite different behavior from this bug here. "

From my experience, you can perfectly well reproduce this problem without having
to beef up up Mozilla/FF/TB memory footprint. In fact, I first came aware of the
problem 3 years ago when so-called quick start feature was implemented in
Mozilla suite. In that case you have small memory footprint without (assumedly)
any page data being held in memory. However, when you "restore" mozilla from
"quick"start date, the delay is extremely painful, 1-3 full minutes with a
watch. It's far faster to kill the mozilla process and start a fresh one. 

Comment WRT photoshop is valid AFAIK. I've been hit hard by this problem at work
when I may not web surf except when coming to work in the morning and before
going home. In the meantime I use memory/resource hungry PCB design apps. A
point of note is, however, that the box itself is chunky with 1GB memory and it
does not help on the problem to close the design tools first. There is no clear
correlation of available RAM vs the delay. 

I have seen this problem on NT4, W2k and XP. I have NOT seen this problem on
W98. AFAIK the problem is WIN32 only. 

If you check the performance monitor graph from the now-defunct bug,
https://bugzilla.mozilla.org/attachment.cgi?id=164163, you can see how mozilla
and FF take very long time to actually kick in with the page-in process. The low
page fault activity takes easily over 60 seconds there before the actual swap-in
process kicks in which only takes 5 seconds or so. In practice this means you do
not see HDD trashing while Mozilla/FF/TB is having it's "beauty sleep" and
you're tapping your fingers waiting it to become active. 

I'd conclude the evidence points out to the problem not being paging performance
at all, but instead gecko codebase doing "something" which involves long/repeat
timeouts. Font access sounds good in theory, but it should result in HDD
trashing with the HDD light coming up. 

I do propose the best way to root out this problem would be to perform basic
analysis on module level to find out which module in fact generates the
>60second delay. There was such activity "early" in the old bug
(https://bugzilla.mozilla.org/show_bug.cgi?id=76831#c94) but it never really
touched the problem as they were only seeing <10sec delays. 

If I had access to a test build of mozilla/FF which dumps the delay times into a
file I could perform the tests myself, but I do not have option to build test
binaries myself. 

Comment 10

[Kenny Lee]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b2) Gecko/20050701
Firefox/1.0+

This bug is still happening. Been having this bug for a very long time.

I am using Windows XP Pro with SP2 (post-SP2 patches are installed too)

If I left Firefox idle while watching a video, once I get my focus back to
Firefox, it somehow loads slowly and and on occasion freezes before going back
to normal. Which also would take a while for it to get back to normal. About 1
to 2 mins.

Comment 11

[Brendan Eich [:brendan]]

(In reply to comment #10)
> If I left Firefox idle while watching a video, once I get my focus back to
> Firefox, it somehow loads slowly and and on occasion freezes before going back
> to normal. Which also would take a while for it to get back to normal. About 1
> to 2 mins.

Did you see hard disk activity, or run a performance monitor that showed what
kind of operating system activity was going on?

People who want to help here, please try to observe what the system is doing
during the minutes it takes for the Gecko app to get back to normal.  Olli said
it wasn't HDD activity, so it wasn't paging.  If others can confirm, that helps.
If others can measure what *is* going on at the OS (i/o, virtual memory, font
handle and other graphics resources) level, that helps even more.

/be

Comment 12

[Kenny Lee]

In my case, there is Hard Disk activity. while I wait for Firefox to get back to
normal, if I alt-tab to another application, it is just like a normal alt-tab.
Firefox is still in the process of getting back to normal, and my hard disk
activity light continued to be active until firefox got back to normal. CPU
usage hits the roof with 80-100% at the same time. some application tend to also
get lagged down in the process. 

After firefox got back to normal, there is still some hard disk activity and
loading tabs and websites still lags or freezes(rare). After a while, firefox
get back to normal.(usually about 2minutes to 3mins after)

Comment 13

[Brendan Eich [:brendan]]

Also, anyone who wants to help, say how much RAM your system has, and if
possible, how big the Gecko app's process has grown.

/be

Comment 14

[Kenny Lee]

I have 512MB RAM.

Comment 15

[Olli Männistö]

Couple of clarifications on my report. I measure things with
config.trim_on_minimize=true and do NOT load firefox/mozilla with a bunch of
tabs. I have just my homepage open which generates about 20MB working set for
FF. However, on this setup I still get 30sec - 60 sec recovery time for
mozilla/FF. Browser window comes up a bit faster, but it takes more time for the
browser to become actually responsive (menu clicks).

I took a fresh perfmon graph for mozilla 1.82b. What I think is significant is
that the page fault count stays at about 100 faults/sec and it takes looong time
to get working memory from about 7MB to about 14MB. I division line in the graph
is 4 seconds. You work the time from there. 

When I try this same with photoshop elements or some other app, the page fault
count goes off the scale to about 4000 page faults/second peak, which is
probably what this system is capable of at maximum with the corresponding 30x
difference in "restoring app from minimized". Also when photoshop is doing that,
the system is truly loaded and becomes sluggish. 

Comment 16

[Olli Männistö]

Attachment: Perfmon graph of minimized mozilla 1.8b2 restoring with trim=true

Comment 17

[Olli Männistö]

Attachment: Perfmon graph of photoshop elements editor being restored with 3 images open

Here's a bit more representative perfmon graph for photoshop. I quess the 4k+
page faults I saw earlier was really from disk cache. This one was taken after
the box had been sitting idle over weekend + photoshop had not been touched for
a full working day. 

Last 2 peaks of page faults are when I clicked on the 2 other images "open",
the app itself was responsive after 12 seconds or so. Note page fault peaks
around 500/second. 

In fact, I'm seeing similar behavior from FF 1.03. The FF working set tends to
"creep" back up slowly after you have minimized it and
config.trim_on_minimize=true. Without being touched and being constantly
minimized. In fact, I just went for a lunch and in the meantime the working set
had grown from 2.5MB to 17MB. That explains why I'm not seeing the slow restore
problem, if FF becomes un-trimmed after a while. 

Every time I've seen the anomalous delay becoming responsive, it has been
accompanied with the page faults staying in 50-100/sec range, give or take a
little. So no real disk trashing.

Comment 18

[Adam Guthrie]

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

Comment 19

[David :Bienvenu]

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

Comment 20

[Hari Kumar G]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20050905
Firefox/1.6a1

On win2k sp4+ 

If the user is continuously switching between applications there is no delay in
the reaction time.  The worse scenario is activating Firefox from idle stage of
some minutes.  The performance graph shows 100% usage.  Also the window
redraw/refresh does not happen for about 20-30 secs.  The contents of previously
active window are visible along with the title bar of firefox.  The 'reaction'
to mouse click on tabs or anything doesn't work for a while.

It seems like firefox is doing an 'assessment' of previous state.

Comment 21

[Adam Guthrie]

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

Comment 22

[Andreas Morawietz]

I have this problem on many systems and I can't explain why.

I think, this bug should be fixed before releasing FF 1.5  

blocker?

Comment 23

[Adam Guthrie]

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

Comment 24

[tccondon]

This bug also occurs on Windows 2000.

Comment 25

[Wayne Mery (:wsmwk)]

do you still see this using FF 3 RC1?

http://www.mozilla.com/en-US/firefox/all-rc.html

Comment 26

[Wayne Mery (:wsmwk)]

=> WFM FF3.0.3