121330 - Large document with lots of markup slows Mozilla down to a crawl

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Peter Anvin]

The indicated URL is 12 MB in size, mostly one big <pre> tag with embedded
<span> tags.  It causes Mozilla to slow down to a crawl while rendering;
furthermore, not just the window rendering the data set in question is affected,
but all Mozilla windows, including News/Mail.

The same behaviour was observed when the <pre> tag was removed and formatting
was enforced with &nbsp; and <br> instead.

Comment 1

[Peter Anvin]

This is tested with Mozilla 0.9.6 on Linux/i386, RedHat 6.1.

Comment 2

[Damian Yerrick]

On build 2002011604 on my Windows ME box with an 866 MHz PIII and 128 MiB
of RAM, I get a *slight* amount of slowdown until Mozilla starts to dig
into swap (Wintop reported over 120 MB allocated before I closed the tab).
Then it slows to a crawl when switching windows.  But to Mozilla's credit,
it doesn't slow down any more than the other running apps (namely Explorer,
Cool Edit, and Outlook Express) while that page is loading.

Peter: i386?  Who uses a 386 anymore? :-)

Reporter: How fast is your machine?  How much memory?  Is its hard disk
making the characteristic sounds of swapping?

Comment 3

[Boris Zbarsky [:bzbarsky]]

likely a dup of other "large flat document" bugs.  Will profile later tonight or
tomorrow.

Comment 4

[Peter Anvin]

i386 as in the i386 (32-bit PC) architecture.  The machine is a dual PIII/800
with 1 GB RAM.  No swapping is noticeable.

Comment 5

[Christopher Whitt]

No noticeable slowdown on Win98 2002011703.  I'm running an Athlon XP1600+ with
256MB RAM.  Maybe this is platform specific

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: profile

Comment 7

[Boris Zbarsky [:bzbarsky]]

To layout.  nothing immediately jumps at me here.  ccing waterson who has
similar bugs on his plate already.

Comment 8

[Chris Petersen]

Changing QA Contact

Comment 9

[Amarendra Hanumanula]

 Even IE hangs on loading the above URL on WIN2K. Changing the OS to all and 
priority to P2

Comment 10

[Vedran Miletic]

retargeting

Comment 11

[Boris Zbarsky [:bzbarsky]]

.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Hmm... the url now points to a far smaller document... (I was going to retest
because the top culprits in that profile had gotten some nontrivial speedups). 
Is there still a testcase for this bug?

Comment 13

[Boris Zbarsky [:bzbarsky]]

No testcase, no useful way to reproduce, so marking worksforme.  Please reopen
if there is a testcase....

Comment 14

[Peter Anvin]

Corrected URL and reopening

Comment 15

[Boris Zbarsky [:bzbarsky]]

OK, loading that file I see the following:

Total wall-clock time to load from local disk (so network is not the limiting
factor; I copied the CSS locally too):  1 minute 45 seconds.  For comparison,
lynx took about 30 seconds to display the same file.

Mozilla memory usage when done: 180 MB

Mozilla stays responsive throughout the load; I was opening new windows, typing
in URIs, etc as I was loading the file.  It's not quite as quick as when there
is no load on the system at all, but it _is_ using nearly 100% of CPU (which
makes sense -- it's rendering a page).

A profile shows nothing untoward -- 6% of time is spent in RecoverFloats (see
bug 226737 and bug 86950).  Time is spent in frame construction, parsing,
content model construction, reflow, in about the proportions you'd expect.

So what exactly is the problem?  Being able to do a whole lot more work than
lynx in a comparable amount of time (factor of 4 is not too bad, considering)
and without being unresponsive at any point seems like about the best that we
can achieve...

Comment 16

[Wayne Mery (:wsmwk)]

FF does better here than IE as far as I can tell.  ANd FF doesn't seem long considering the size of the document.  on vista and Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008020404 Minefield/3.0b3pre

No changes in bug 86950 (floats)

Comment 17

[Peter Anvin]

Seems to work okay nowadays...

Comment 18

[Wayne Mery (:wsmwk)]

Peter, what do you mean by "works"?

Did you try menus? Menus didn't work at all for me - which might be a different bug. (I'm not sure what all I tested in comment 16 so it's hard to compare to a year ago - sadly I didn't record timings)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090621 Minefield/3.6a1pre (.NET CLR 3.5.30729)