Open Bug 64858 Opened 24 years ago Updated 2 years ago

2666 seconds to load large page.

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect, P4)

x86
Linux
defect

Tracking

()

Future

People

(Reporter: jamie, Unassigned)

References

(Depends on 1 open bug, )

Details

(Keywords: helpwanted, perf, Whiteboard: [reflow-refactor])

Attachments

(2 files)

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 :).
Please always include build ID in bug-reports.
All versions since I first discovered the site a few months ago :)

Currently running 2001010517
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
confirming for now.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: hang, perf
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
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:
   http://www.damowmow.com/mozilla/bugs/slow/002.html
Waterson says it might be a dup of bug 56854.
Depends on: 56854
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).
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).
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.1 → mozilla0.9.2
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
PresShell::ContentAppended)

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.
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...
> 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|).
Component: ImageLib → Image: Layout
At this point, the top caller in the flat profile is
nsSpaceManager::GetFrameInfoFor()
Is this bug somewhere depending on bug 78911 or bug 90725?
Whiteboard: [reflow-refactor]
Depends on: 349113
On those testcases, I see the following times:

Trunk:
  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.
Depends on: 349200
Depends on: 349206
Reflow branch with the patches for bug 349113 and bug 349200 gives me about 15s times on the "img tags" testcase.
Depends on: 351586
QA Contact: tpreston → layout.images
Product: Core → Core Graveyard
Product: Core Graveyard → Core
Assignee: waterson → nobody
Status: ASSIGNED → NEW
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.