All users were logged out of Bugzilla on October 13th, 2018
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
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).
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.
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|).
Waterson: no need to implore! :-) http://www.damowmow.com/mozilla/bugs/slow/002-no-img.html
At this point, the top caller in the flat profile is nsSpaceManager::GetFrameInfoFor()
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.
You need to log in before you can comment on or make changes to this bug.