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.
In addition, dragging the mouse pointer over the page in order to select some text is painfully slow as well.
over to layout. I think there are already reports of this problem.
setting bug status to New
Nisheeth, is this perhaps related to your incremental layout stuff?
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.
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.
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.
Related to bug 77540? I'll check when I'm sure the patch on that bug is in one of the builds
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.
I'm getting this consistently with long pages (Well conferencing topics) on the Mac version 0.93. Hope you fix it soon.
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.
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).
*** Bug 77540 has been marked as a duplicate of this bug. ***
I see a 10x improvement on the original testcase (mysql documentation) on the reflow branch.
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...
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.
Fair enough. We had a big win here from reflow branch, so it's not like we've regressed performance on this testcase.