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.

--> networking: 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.

CONFIRMED Linux 20010215

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.

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

Moving to m1.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.

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.

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.

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 moved)

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

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.

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.