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.

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

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?

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

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

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

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

Changing QA Contact

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

retargeting

.

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?

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

Corrected URL and reopening

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...

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)

Seems to work okay nowadays...

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)