67756 - File loads ~14X slower than NS4.76

Status: RESOLVED WORKSFORME

(Core :: Networking, defect)

Description

[Jeremiah Savage]

From Bugzilla Helper:
User-Agent: Mozilla/4.76 [en] (X11; U; Linux 2.4.1 i686)
BuildID:    2001020512

Attempting to load a large (3.4MB) html file on *local* storage takes a very
long time. This example file is "The GNU C Library Reference Manual" and
requires ~165 seconds to load on a PII-400 running Debian/Sid/Linux-2.4.1. The
same file loads in ~12 seconds in Netscape 4.76.

I have placed a copy of the test file at:
http://users.abac.com/jsavage/libc.html.bz2

If you web browser decides to download the file as garbage to your
browser window, you can go to:
http://users.abac.com/jsavage/index.html

and do a "save as..." on the file.

Reproducible: Always
Steps to Reproduce:
1. download libc.html.bz2
2. bunzip2 libc.html.bz2
3. load libc.html

Actual Results:  I waited ~165 seconds for the file to load.

Expected Results:  If NS4.76 is an optimized benchmark, the file should load in
~12 seconds.

Comment 1

[Doron Rosenberg (IBM)]

--> networking: file

Comment 2

[Jeremiah Savage]

Attachment: 3.4MB html file

Comment 3

[Jeremiah Savage]

Just a confirmation that Mozilla 0.8 (BuildID: 2001021503) shows the same
performance problem:
I tried the libc.html file on my PII-400/128MB and loading took 151.077 seconds.
During this time 'top' reported a consistent >95% CPU by the Mozilla process.

Comment 4

[Agustín Fernández]

CONFIRMED
Linux 20010215

Comment 5

[James Green]

Same as what I'm seeing with http://cvsbook.red-bean.com/cvsbook.html.gz which
is also bloody slow to load after the first-half has been rendered. mozilla
(linux) seems to hang during this. Note that this page doesn't have any tables
in it.

Comment 6

[Doug Turner (:dougt)]

The ball is snapped.  Dougt sees Waterson down field.  Left, right, he throws.  
Its a long one.  Waterson turns.. got it.  runs..  it looks like a touchdown...

Comment 7

[karnaze (gone)]

Moving to m1.0.

Comment 8

[wing-tung Leung]

It seems to work fine now, download in ~12 seconds. The gzipped HTML page about
CVS loads quickly too.

using milestone 0.9 on GNU/Linux i386

Good for "Solved" status?

Comment 9

[Chase Tingley]

I just tested the libc.html file with 0.9 Linux; it loaded in 64 seconds, during
which time 'top' reported 98-99% CPU utilization by mozilla.  Machine is
PIII/800; I wouldn't change the status quite yet...

Comment 10

[benc]

mass move, v2.
qa to me.

Comment 11

[Paul Kelly]

54.0 seconds to load/render libc.html on a P-III 800MHz with oodles of RAM.
Nightly build from August 1st under Linux (RedHat 7.1).

Subjectively, load speed appears to vary in proportion to the number of links in
a given section. With the links stripped from the document, but still in HTML
format, it takes 44 seconds to load 3.0MB so the problem isn't the links alone.

Renamed to .txt, the original 3.4MB document takes 29.4 seconds to load. 

Disabling disk and memory cache appear to have no effect.

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

I'll try to jprof this one.  Probably similar to the results I have jprofing
jprof pages.

Comment 13

[Randell Jesup [:jesup] (needinfo me)]

I jprof'd this.  On a dual-450 PIII linux RH7.1 box, ns4.77 takes about 6
seconds to load this page; mozilla takes about 120 (20x slower, not 14x).

I'll upload the jprof, and later do some analysis.  Quickie things I've noticed:
The biggest obvious culprit (1/4 of execution time) is recovering vertical
margins (bug 86497).  We also spend a lot of time building frames and in
incremental reflow.

This is another case of the "big pages load slowly" bug.

Comment 14

[Randell Jesup [:jesup] (needinfo me)]

Attachment: 800K jprof of loading 3.4MB attachment. period=.002, dual 450's linux

Comment 15

[Randell Jesup [:jesup] (needinfo me)]

of 4598 hits (%'s are all of this number)

2579 (57%) in PresShell::ProcessReflowCommand
  2507 (56%) in nsBlockFrame::ReflowDirtyLines
    1349 (30%) in nsBlockFrame::RecoverStateFrom
      1002 (22%)  in nsBlockReflowState::RecoverVerticalMargins
       207 (4.5%) in nsBlockFrame::SlideLine
          42 (0.9%) directly
         113 (2.3%) in nsBlockFrame::UpdateSpaceManager
     478 (10%) in nsTableOuterFrame::Reflow
     790 (17%) in nsBlockFrame::DoReflowInlineFrames
       652 (14%) in nsLineLayout::ReflowFrame

1352 (30%) in nsParser::ResumeParse
  171 (3.7%) in nsParser::Tokenize
  480 (10%) in CNavDTD::HandleDefaultStartToken
  591 (13%) in SinkContext::CloseContainer
    1030 (22%) nsCSSFrameConstructor::ContentAppended (from both the entries
above this)
      968 (21%) nsCSSFrameConstructor::ConstructFrame
        363 (7.9%) nsCSSFrameConstructor::ResolveStyleContext
          531 (12%) StyleSetImpl::WalkRuleProcessors (includes calls from
elsewhere within ConstructFrame)

Comment 16

[Chris Waterson]

dbaron's changes for bug 86947 are due to land in a week or so. They ought to
have a significant impact on the firts part of that profile.

Comment 17

[Pierre Saslawsky]

DBaron landed his changes yesterday.  Waterson, will you take new measurements?  
I am curious to see if we still spend as much time in CSS parser, style 
construction and style resolution.

Comment 18

[Asa Dotzler [:asa]]

Bugs targeted at mozilla1.0 without the mozilla1.0 keyword moved to mozilla1.0.1 
(you can query for this string to delete spam or retrieve the list of bugs I've 
moved)

Comment 19

[Asa Dotzler [:asa]]

don't move bugs that are in the 1.0 dependency tree. sorry.

Comment 20

[Ronald van Kuijk]

performance on this has improved. 

800MHz/256 MB Linux system:

Netscape 4.76:      9 sec
Mozilla exp-129115: 29 sec
Mozilla 20020426:   32 sec

So only 3x slower....

Comment 21

[benc]

hong: Can someone in perf team take QA of this bug?

Comment 22

[slice1900]

Interesting side note here.  I first downloaded the .bz2 file to a Netscape 4.8
browser window by accident, and it was quicker than the 9 seconds listed in a
previous message, despite my slower machine (Redhat 7.2, 533 MHz Celeron, 768MB
RAM)  I knew I was supposed to be loading the html itself, but I was curious so
I hit reload, and it reloaded it almost instantaneously -- taking less than a
second.  Doing the same on Mozilla 1.2final results in a reload taking 54
seconds.  I confirmed it really is loading it from cache by watching my DSL
traffic light not flicker during this.  This is at least 50x slower!  Granted
there's not much call to download binary data to a browser window, but trying it
with actual text results in a similarly huge difference between NS 4.8 and Mozilla.

Comment 23

[thebeastwitheyesthatstared]

is this bug still relevant with more recent linux software versions? On winxp
for what it is worth, this loads in like 5-10 seconds. (bug cleaning)

Comment 24

[Adam D. Moss]

I just tried the moz1.4 branch (optimized build) versus Netscape 4.8, on
Linux/x86, 750MHz Athlon.

Load times (wall clock):
Mozilla      - 62 sec
Netscape 4.8 - 9  sec

Comment 25

[benc]

Chris, are you going to work on this bug?

If not, please set status to NEW and/or assign to the default owner.

Comment 26

[chris hofmann]

I'd say this is fixed.

Running on my powerbook mac Build identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090405 Shiretoko/3.5b4pre

the initial page loads instantanously, status bar shows done, and I do see a bit of an hour glass as the rest of the content fills in.  during that time I can still scroll and I'd say that it takes about 10 seconds or so to scroll to the bottom of the page going about as fast as I can go.

we ought to get some other trying this to see if they can spot any problems.  the best way to do that might be to mark fixed, so I'll do that.