2666 seconds to load large page.

Assigned to



19 years ago
10 months ago


(Reporter: jamie, Assigned: waterson)


(Depends on 1 bug, {helpwanted, perf})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: [reflow-refactor], )


(2 attachments)



19 years ago
Running Redhat 7.0 w/errata here + kernel 2.4.0.  This was a problem with
2.2.x/mozilla 0.6 as well.  Machine is a 750Mhz PIII with 512 MB ram available,
NS 4.x loaded the page in seconds (cable modems rule :).

Comment 1

19 years ago
Please always include build ID in bug-reports.

Comment 2

19 years ago
All versions since I first discovered the site a few months ago :)

Currently running 2001010517

Comment 3

19 years ago
i tested the site  w/2001-010908 and it froze several times during load, till i
finally killed moz from commandline. Also some weird blinking in between freezes.

The html file in question is around 1.4MB and contains 2 unique small gifs.
One called buyit.gif is repeated 1418 times.
The other, called Photo.gif, is repeated 868 times.

I thought there was an open imagelib bug about this but couldnt find it.
Changing component.
Assignee: asa → pnunn
Component: Browser-General → ImageLib
QA Contact: doronr → tpreston

Comment 4

19 years ago
confirming for now.
Ever confirmed: true


19 years ago
Keywords: hang, perf


19 years ago
Target Milestone: --- → mozilla0.9

Comment 5

19 years ago
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov

Comment 6

19 years ago
Taking. Will profile and get back to you.
Assignee: pavlov → waterson
Target Milestone: mozilla0.9 → mozilla0.9.1
It's not imagelib related. I removed the images and the problem still exists:
Waterson says it might be a dup of bug 56854.
Depends on: 56854

Comment 8

18 years ago
And hey, as an added bonus, because of this line: 

  <META content="text/html; charset=windows-1252" http-equiv=Content-Type>

we load the 2MB document twice!  (see bug 78018).

Comment 9

18 years ago
Sorry, that line is in a copy of the file that waterson gave to me. The 
original url states 'us-ascii' (although that also triggers the double fetch).


18 years ago


18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 10

18 years ago
Okay, this is pretty funny. The main body of the page loads reasonably quickly
on a fast machine (and is probably network bound). But with hixie's version of
the page, you can actually _watch_ the |alt| text for the <image> tags being
popped in, one by one. For an exciting effect, scroll to the bottom of the page
and watch it slowly jiggle downwards; if you're lucky, you can scroll back up,
and find (and follow!) the point where the |alt| text is popping in at a rate of
about two or three <img> tags per second!

Anyway, I'm not too worried about this bug, as the browser appears to be
completely usable during the page load time (it's not ``hung'', IOW). I'm gonna
push this out to future, and we can investigate making the replaced elements
work faster later...
Keywords: hanghelpwanted
Priority: -- → P4
Target Milestone: mozilla0.9.2 → Future
On the same machine, we take a LOT longer than IE to get to the end of the page.
Thus I would suggest this is not bound by the network itself (although I'm not
saying it's not bound by Necko, that's another story altogether...).

Waterson: Did you ever profile this page? It would be interesting to know where
most of the time is spent.
I profiled the first few minutes of the load of Ian's testcase.  It shows some
of our O(N^2) algorithms nicely.

About 3/4 of the time is spent within nsBlockReflowState::RecoverStateFrom.

About 14% is within other parts of reflow:
  About 4% is within nsFrame::Invalidate.
  Includes the following (excluding descendants, of 48300 counts total):
    386  nsBlockFrame::ReflowDirtyLines(nsBlockReflowState &)
    331  nsBlockFrame::BuildFloaterList(void)
    323  nsLineBox::GetCombinedArea(nsRect *)
    261  nsBlockFrame::RecoverStateFrom(nsBlockReflowState &, nsLineBox *, ...
    232  nsLineBox::IndexOf(nsIFrame *) const

About 3% is within PresShell::GetPrimaryFrameFor (from within

About 1% is within nsImageFrame::LoadImage.

About 1% is within style resolution (within nsStyleSetImpl::WalkRuleProcessors).

Slightly under 1% is in the gettimeofday call in nsCacheEntry::Fetched.

Comment 13

18 years ago
No, I didn't profile. As is, I'm not sure I'm going to get all that much useful
information from profiling because _so_ much time appears to be spent _after_
the main body of the page has loaded substituting the |alt| text for <img> tags.
Could I implore upon you to create a new version with the <img> tags stripped
from the test case? I could certainly profile that...

Comment 14

18 years ago
> About 3/4 of the time is spent within nsBlockReflowState::RecoverStateFrom.

This is certainly covered under bug 56854 or one of its dependents (maybe bug
78911 is most appropriate). The interesting thing about this test (as far as I'm
concerned, anyway) is humorous way in which we ploddingly replace the |alt| text
(although I suspect that most of this time is also spent in |RecoverStateFrom|).


17 years ago
Component: ImageLib → Image: Layout
At this point, the top caller in the flat profile is

Comment 17

16 years ago
Is this bug somewhere depending on bug 78911 or bug 90725?
Whiteboard: [reflow-refactor]
On those testcases, I see the following times:

  images: 32379
  no images: 29045
Reflow branch:
  images: 25194
  no images: 15233
Reflow branch with proposed changes for bug 349113
  images: 20635
  no images: 13539
Opera 8.5:
  images: 12936
  no images: 10696

Should retest and reprofile once reflow branch lands.
Reflow branch with the patches for bug 349113 and bug 349200 gives me about 15s times on the "img tags" testcase.
QA Contact: tpreston → layout.images


10 months ago
Product: Core → Core Graveyard


10 months ago
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.