29641 - Layout for pages with long text is very slow

Status: VERIFIED FIXED

(Core :: Layout, defect, P3)

Description

[leger]

Per results on the long page testcase posted internally at:
http://slip/paulw/textlong/text-long.html  (I will look for external posting)

seamonkey takes excessively longer than 4.72 to load the page.

Results:
WinNT 4.0 - 4.72/8.64sec, Seamonkey/19.09sec
Win 98 - 4.72/54.03sec, Seamonkey/1min 20.02sec
Win95 - 4.72/23.77sec, Seamonkey/43.57sec
Mac 8.5 - 4.72/58.41sec , Seamonkey/2min 4.91sec
Mac 9.0 - 4.72/47.97sec , Seamonkey/1min 35.29sec
Linux redhat 6.1 - 4.72/1min 46.06sec , Seamonkey/2min 70.21sec

Comment 1

[leger]

adding beta1 and perf keywords

Comment 2

[troy]

This should not be something we're considering for beta1.

Comment 3

[leger]

Putting on PDT- for beta1.  Will release note.

Comment 4

[vidur (gone)]

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

Comment 5

[vidur (gone)]

An external URL (or attached test case) would help greatly. I was trying to look 
at this with Johnny Stenback (who's outside the firewall) and he couldn't get to 
it.

Comment 6

[Sebastian Späth]

Changing the URL field from the internal
http://slip/paulw/textlong/text-long.html to an external URL. I imported it from 
duplicate bug 25734, it's a >9MB file containing lots of text.

Comment 7

[troy]

Changing the URL back to what it was. The new URL (compaq site) is on a very 
slow server, it's 50% larger document, and it's not all text so it is not a 
suitable replacement

Comment 8

[Chris Petersen]

Added keyword nsbeta2.

Comment 9

[leger]

Putting on [nsbeta2-] radar.

Comment 10

[buster]

reassigned to me

Comment 11

[Chris Waterson]

dbaron & I have made some big changes that may affect this. I'll take the bug 
for now...

Comment 12

[ekrock's old account (dead)]

Nominating for nsbeta3 review as a perf bug. The UE when this bug occurs is
quite painful--initial page layout took 105s on my WinNT 4.0 SP4 with a P2-300
and 256M RAM, and the browser freezes for a long time during initial layout. (In
fact, it seemed to seize control of the cursor so I couldn't remove the cursor
from the browser window and had to CTRL-ALT-DEL and Cancel to regain the ability
to put the cursor outside the browser window; but the browser itself hadn't
crashed and finished the layout operation successfully.)

If the problem is truly specific to documents that have "long text" and we lack
evidence for actual popular pages on the web that are causing this, it could be
FUTUREd.

Comment 13

[ekrock's old account (dead)]

[nsbeta3+].

Comment 14

[Peter Trudelle]

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

Comment 15

[Chris Waterson]

Attachment: remove "backoff count"

Comment 16

[Chris Waterson]

The next thing that we should do is remove the "backoff count". On large 
documents, this stifles reflows after a certain point, and ends up getting 
layout into a situation where it must synchronously reflow thousands and 
thousands of frames.

nisheeth, vidur, or jst, could you r=? (After which I'll make the bug 
[nsbeta3-] and future it -- I'm sure there is still plenty of evaluation that 
could go on here.)

Comment 17

[Nisheeth Ranjan]

r=nisheeth.  I suggest that you run this change by vidur also because he
implemented the backoff count.

Comment 18

[Chris Waterson]

Did the fix vidur suggested, which was to just pick a really big default value
for the backoff count. I'm going to mark this bug fixed, as it solves the
problem ekrock rants about, above. Of course, there is always room for
performance improvement, so I'd like to deal with those as we identify areas for
enhancement.

Comment 19

[nivtwig]

Sorry, but this bug is not fixed yet. I tried creating an attachment but it 
gave me an error, so try a long detailed bugzilla bug list(>1MB) and save it to 
disk, then reload from disk. On win98 it takes more than about 90 seconds on 
Mozilla, compared to less than 5 seconds on IE and Netscape.

Comment 20

[Chris Waterson]

niv: read the last comment. file a new bug.

Comment 21

[Chris Petersen]

Marking verified per last comments of waterson.

Comment 22

[Chris Waterson]

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