Extreme slowness when loading long pages of text from disk

ASSIGNED
Assigned to

Status

()

Core
Layout
P3
normal
ASSIGNED
17 years ago
5 years ago

People

(Reporter: bugzilla, Assigned: Chris Waterson)

Tracking

({perf})

Trunk
Future
x86
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [reflow-refactor], URL)

(Reporter)

Description

17 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.
(Reporter)

Comment 1

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

Comment 2

17 years ago
over to layout.  I think there are already reports of this problem.
Assignee: asa → clayton
Component: Browser-General → Layout
QA Contact: doronr → petersen

Comment 3

17 years ago
setting bug status to New
Status: UNCONFIRMED → NEW
Ever confirmed: true
Please triage.
Assignee: clayton → joki
Nisheeth, is this perhaps related to your incremental layout stuff?
Assignee: joki → nisheeth

Comment 6

17 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.
Assignee: nisheeth → karnaze

Comment 7

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

Comment 8

17 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.
Assignee: karnaze → waterson

Updated

17 years ago
Keywords: perf
(Assignee)

Updated

17 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1

Comment 9

17 years ago
Related to bug 77540?

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

Updated

17 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2
(Assignee)

Updated

17 years ago
Target Milestone: mozilla0.9.2 → mozilla1.0

Comment 10

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

Comment 11

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

Updated

16 years ago
Target Milestone: mozilla1.0 → mozilla0.9.6
(Assignee)

Updated

16 years ago
Blocks: 71668
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.6 → mozilla0.9.7
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.7 → mozilla0.9.8
(Assignee)

Updated

16 years ago
Target Milestone: mozilla0.9.8 → Future

Updated

16 years ago
Keywords: mozilla1.0+

Comment 12

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

Comment 14

14 years ago
*** 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.
Whiteboard: [reflow-refactor]
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.
QA Contact: chrispetersen → layout
You need to log in before you can comment on or make changes to this bug.