All users were logged out of Bugzilla on October 13th, 2018

2666 seconds to load large page.

ASSIGNED
Assigned to

Status

()

P4
normal
ASSIGNED
18 years ago
2 months ago

People

(Reporter: jamie, Assigned: waterson)

Tracking

(Depends on: 2 bugs, {helpwanted, perf})

Trunk
Future
x86
Linux
helpwanted, perf
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [reflow-refactor], URL)

Attachments

(2 attachments)

(Reporter)

Description

18 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

18 years ago
Please always include build ID in bug-reports.
(Reporter)

Comment 2

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

Currently running 2001010517

Comment 3

18 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

18 years ago
confirming for now.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

18 years ago
Keywords: hang, perf

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9

Comment 5

18 years ago
All pnunn bugs reassigned to Pav, who is taking over
the imglib.
Assignee: pnunn → pavlov
Status: ASSIGNED → NEW
(Assignee)

Comment 6

18 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:
   http://www.damowmow.com/mozilla/bugs/slow/002.html
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).
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
(Assignee)

Updated

18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2
(Assignee)

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: hang → helpwanted
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.
(Assignee)

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...
(Assignee)

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

Updated

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

Comment 17

15 years ago
Is this bug somewhere depending on bug 78911 or bug 90725?
Whiteboard: [reflow-refactor]
Created attachment 234364 [details]
Zipped up testcase with <img> tags (all broken)
Created attachment 234365 [details]
Same, but without <img> tags
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.
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

Updated

2 months ago
Product: Core → Core Graveyard

Updated

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