76151 - Extremely slow leaving big page

Status: RESOLVED WORKSFORME

(Core :: CSS Parsing and Computation, defect)

Description

[Daniel Bratell]

It now takes 20 seconds to load the colour stress table case, but it takes 60
seconds without visible cues leaving it.

STEPS TO REPRODUCE:
1. Go to http://www.google.com/
2. Go to http://www.mozilla.org/newlayout/testcases/stress/wbtblclr.html
3. Wait for it to load (10-60 seconds depending on computer speed).
4. Press the back button.

EXPECTED RESULT
5. See the Google page immediatly

ACTUAL RESULT
5. Nothing but a non standard mouse pointer. But if you wait a minute or two you
will come to the Google page.

COMMENTS
I see this as a bigger useability problem then slow loading since is is a common
operation and for the user it looks as if the browser has hanged. The user can't
see any reason for the operation to be slow either. (Neither can I).


This was on a home built Mozilla from April 13, 2001 or something like that.

Comment 1

[R.K.Aa.]

hmm. linux cvs build (non-psm) from around midnight CET re-renders the google
page after approx 3-4 sec. (p3/500). Not as snappy as NC4.* but way faster than
what you observe.

Comment 2

[Daniel Bratell]

Hmm. Could it be something that is Windows only maybe (or worse, my system 
only)? How did you go back? I clicked on the back button with the mouse. I've 
seen this for a while but have not filed a bug until now.

Comment 3

[Junk_HbJ]

Wfm 2001041508 / Win98SE.

Comment 4

[Daniel Bratell]

I spent some time in quantify to see what it was and found the following:

95% of the time was spent in nsDocShell::SetupNewViewer because it assigned 
something with assign_with_Addref to a nsCOMPtr which cause the previous content 
(a DocumentViewerImpl) to be released and therefore destroyed. 
94% of the total time was spent in 1 call to the DocumentViewerImpl destructor 
which released 30000 nsTextInputListener times which caused a PresShell to be 
deleted. 

That caused two things to happen. A FrameManager was destroyed (thats 25% of the 
total time) and the styles (through StyleSetImpl) was released (~75% of the 
time). The 75% seems to be memory releases. A lot of 
PLHashTableEnumerateEntries, HashTableEnumDestroy, nsVoidArray::~nsVoidArray, 
hashFreeEntry and stuff. I wonder if this will improve with the memory pooling 
of stylesets.

The 25% (A destroyed FrameManager) is caused by a destroyed ViewPortFrame which 
destroys the list of frames (there are 20126 frames).

Conclusion:
All the time is spent deallocating memory and the actual time depends on the 
state of the heap when going back. I guess my heap has been in really bad shape 
for some reason which is why it is slower for me than for the others who have 
tested. 

Since the biggest speedup will come from the styles being better handled in 
memory, I will make this bug blocked by the pooling styles bug (bug 65266).

Comment 5

[R.K.Aa.]

I used the back-button. Repeated it too, going forward to the stresstest
again - and then back once more, to see if something changed.

This is a fairly vanilla non-debug build with mailnews. Java_vm was triggered
while i tested. Also have flash registered. None of these had actually been used
in the session i tested in though.

Other info:
512MB RAM
272636 byte history file
84974 bookmarks file
Cache had been wiped clean the same day.

Comment 6

[Pierre Saslawsky]

Old bug: WorksForMe now...