Closed Bug 67756 Opened 22 years ago Closed 14 years ago

File loads ~14X slower than NS4.76


(Core :: Networking, defect)

Not set





(Reporter: jeremiahsavage, Unassigned)




(Keywords: perf)


(2 files)

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:

If you web browser decides to download the file as garbage to your
browser window, you can go to:

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.
--> networking: file
Assignee: asa → dougt
Component: Browser-General → Networking: File
Keywords: perf
QA Contact: doronr → tever
Attached file 3.4MB html file
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.
Summary: File loads ~14X slowers than NS4.76 → File loads ~14X slower than NS4.76
Linux 20010215
Ever confirmed: true
Keywords: nsbeta1
Target Milestone: --- → mozilla0.9.1
Blocks: 72885
Blocks: 71668
Same as what I'm seeing with 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.
Component: Networking: File → Networking
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...
Assignee: dougt → waterson
Target Milestone: mozilla0.9.1 → ---
Moving to m1.0.
Target Milestone: --- → mozilla1.0
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?
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...
mass move, v2.
qa to me.
QA Contact: tever → benc
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.
I'll try to jprof this one.  Probably similar to the results I have jprofing
jprof pages.
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.
Depends on: 86947, 97229
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)
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.
Blocks: 104166
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.
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 
Target Milestone: mozilla1.0 → mozilla1.0.1
don't move bugs that are in the 1.0 dependency tree. sorry.
Target Milestone: mozilla1.0.1 → mozilla1.0
Target Milestone: mozilla1.0 → Future
Keywords: mozilla1.0+
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....
hong: Can someone in perf team take QA of this bug?
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.
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)
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
Chris, are you going to work on this bug?

If not, please set status to NEW and/or assign to the default owner.
Assignee: waterson → nobody
QA Contact: benc → networking
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.
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.