bugzilla Reporter
	Description • 24 years ago

Mozilla takes a long time to load large pages of text from disk
and becomes unresponsive during loading.

As an example, I have supplied the URL for the MySQL manual.
Copy this page to a local disk and open it in Mozilla.

Mozilla (build ID 2000101921) takes about 35 seconds to fully
load and display the page on a 550MHz PIII. During this time,
scrolling using the mouse wheel and the scroll bar becomes
jumpy. Navigator 4.75 takes only about 8 seconds to load the 
same document and does not suffer the same lack of 
responsiveness.

Mozilla is also slower than Navigator when loading the page
from the network, but the difference is not so outspoken.

	bugzilla Reporter
	Comment 1 • 24 years ago

In addition, dragging the mouse pointer over the page 
in order to select some text is painfully slow as well.

	Asa Dotzler [:asa]
	Comment 2 • 24 years ago

over to layout.  I think there are already reports of this problem.

	Asa Dotzler [:asa]
	Comment 3 • 24 years ago

setting bug status to New

	Heikki Toivonen (remove -bugzilla when emailing directly)
	Comment 4 • 24 years ago

Please triage.

	Heikki Toivonen (remove -bugzilla when emailing directly)
	Comment 5 • 24 years ago

Nisheeth, is this perhaps related to your incremental layout stuff?

	Nisheeth Ranjan
	Comment 6 • 24 years ago

This has become much better after waterson's changes to text layout.  
Re-assigning to karnaze, the layout group's manager, for future tracking and 
ccing waterson.

	Andrew Thompson
	Comment 7 • 24 years ago

Right. For another example see 

http://java.sun.com/products/jdk/1.1/docs/api/AllNames.html

(save it to disk or load it off the web, it doesn't ultimately matter).

Netscapw 4.X can do this page  in 12-15 seconds where mozilla takes 25-33. 
Mozilla feels much worse because scrolling is jerky and other apps are effected.
I remember when it was more like 1 minute, back in the mid-teens milestones, but 
its still to slow. As one person commented on one of the old bugs 'on a decent 
machine, Mozilla should be able to load a meg of html 2.0 off a local faster than 
I can fart'. I like the turn of phrase...

I'm seeing this primarily on Mac OS. I can file a sperate bug if you like, or 
change the platform OS to all, since I don't believe this is ultimately platform 
specific.

	karnaze (gone)
	Comment 8 • 24 years ago

Waterson, I compiled with DEBUG_TABLE_REFLOW_TIMING on WinNT and found that 
table reflow is not to blame. Can you have someone quantify this.

	Andrew Thompson
	Comment 9 • 24 years ago

Related to bug 77540?

I'll check when I'm sure the patch on that bug is in one of the builds

	Christian Reis
	Comment 10 • 23 years ago

Has something developed during this time? I find the performance for long text
pages extremely bad, and the CPU usage will shoot up for anything you do with
the page - even mouse moving over the text makes the browser sluggish.

I'm looking for a practical way to test what's happening. If somebody can
profile while running Moz, it's easy to create a testpage: just run "yes foo >
foo.txt" till foo grows to about 2MB and then try loading it.

	Avi Rappoport
	Comment 11 • 23 years ago

I'm getting this consistently with long pages (Well conferencing topics) on the
Mac version 0.93.  Hope you fix it soon.

	Mark Pulver
	Comment 12 • 22 years ago

I have more timing numbers for this problem...

Reference this page (warning, it's a big flame fest):

http://www.the-gas-station.com/messages.cfm?type=messages&thread_id=47624

With a T3 line for bandwidth, Mozilla v1.1b will take 72 seconds to load and
render the page. IE will show it in about 10 seconds. The large spread in time
can also be seen when loading the page locally.

Looking at the source of the page, it looks like the issue may come from the
amount of formatting. There are a large number of table objects on that page.

	Boris Zbarsky [:bzbarsky]
	Comment 13 • 21 years ago

Anything with lots of tables is likely to be a different issue from the original
bug (which had no tables).

Profiling this I see nothing leaping out, just the usual "we're implementing too
many W3C specs" kinda things (and the fact that font metrics needs
deCOMtamination, but that's got a bug filed).

	Keyser Sose
	Comment 14 • 21 years ago

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

	Boris Zbarsky [:bzbarsky]
	Comment 15 • 18 years ago

I see a 10x improvement on the original testcase (mysql documentation) on the reflow branch.

	Boris Zbarsky [:bzbarsky]
	Comment 16 • 17 years ago

So on trunk about a sixth to a quarter of the total time is under nsTextFrame::Reflow.  This is with the manual in http://downloads.mysql.com/docs/refman-4.1-en.html.tar.gz

roc, want to take a look?  I suspect it's just "lots of text", but...

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 17 • 17 years ago

I don't really want to spend time on this unless someone argues it's a blocking issue. I assume that we've improved a lot in 1.9 already; I'd rather focus on where we've regressed.

	Boris Zbarsky [:bzbarsky]
	Comment 18 • 17 years ago

Fair enough.  We had a big win here from reflow branch, so it's not like we've regressed performance on this testcase.