Tested on Mozilla MTrunk build 2000103104 Loading this page: http://docs.iplanet.com/docs/manuals/ias/60/JavaProgGuide/jpgdeplo.htm#11284 Takes forever to load. Symptoms: Blank page for up to 2 minutes and all open Mozilla browsers are locked up. It then finally loads. I had a report from one user on #mozillazine who said that it loaded, but just flashed the content and disappeared. I did not see that, but I can believe it based on this strange behavior. To Reproduce: 1. Open said link in Mozilla 2. Wait and/or try to view other mozilla windows or move the current window. You will have no such luck 3. After 1 - 2 minutes, the page should display and mozilla will cease to be locked up Jake
Yeah, I'm seeing that same behavior under Linux with a PIII 933 and 128 Mb RAM. Definitely an issue. Marking confirmed.
Changing crasher bug milestone to mozilla0.9.
Nisheeth, this is a potential dupe of bug 57451.
The performance on this page was significantly worse than the performance on the page linked from bug 57451. So, I am not marking this bug as a dup of 57451. This bug belongs to the layout camp. Re-assigning to Chris Karnaze, the layout manager.
nsCSSFrameConstructor::ReframeContainingBlock is getting called too many times, and I suspect that this is the problem. nsCSSFrameConstructor::WipeContainingBlock gets called also. Reassigning to Buster.
I can take a look...
Just profiled this: as karnaze notes, 64% of the time is spent in 163 calls to nsCSSFrameConstructor::ReframeContainingBlock().
End-of-milestone reality check.
Another page which loads very slowly is http://www.warcraftiii.net. I'm not sure if this is another bug, but I made an interesting observation: Wait until the page loads, then scroll it with the scrollthumb. It seems that the further down you scroll, the slower it gets. If you scroll back up, performance becomes better again. There's no visible difference in the page layout, though. Please note that both the HTML in iplanet as well as in warcraftiii.net is a huge mess. The W3C validator gives lots of error about wrongly nested tags. Perhaps the parser gets confused and creates a broken tree. I'll try to fix the HTML, so that we can see if it makes a difference
Created attachment 36461 [details] [diff] [review] optimize ContentAppended() to avoid reframe when possible
Okay, this particular page (iplanet docs) ended up not being too hard to deal with. It turns out that most of the time (all of the time, on this page), we're appending to the anonymous block that gets created when an inline frame is split. When that is the case, we can just let the normal frame construction logic do its magic. The basic idea is to - check if the parent frame is ``special'' (that is, it's an inline frame that's been split into inlines surrounding a block) - advance to the parent's last ``special'' sibling (since we're appending, we know this is where the new frames must be added) - if the last sibling is the anonymous block frame, then we can go ahead and use the normal frame construction logic. If not, then reframe. (Note that ConstructInline() and SplitToContainingBlock() only create a ``trailing'' inline frame if there are actually child frames that need to live there.) The above patch drops the page load time from 24s on my machine to l.t. 2s.
The patch look good Chris: [s]r=attinasi if you want/need it.
r=karnaze, assumming all regression tests pass. Chris, I'm not sure how many block tests actually cause frames to be split, but if there aren't very many, you might consider adding a few (just a suggestion).
Will do. I'll make some regression tests right now to stress this code.
Er, Waterson? You seem to have forgotten the definitions of "do_append()" in those tests...
Oh, heh. It's vestigial. I'll nuke it. It turns out that the DOM calls always end up calling ContentInserted(), so I needed to do some tomfoolery with document.write() to get ContentAppended() to be called at the right times.
Allright, fix is in, a=chofmann.
Great, realy greay improvement. More than a 1000% win from 250s. to 23s on an initial (clear cache) load. Still some inprovement (probably other bugs) cause ns4.7x only takes 12s. Still a great improvement. One question however. Why does it take almost twice as long (39s) when I do a shift-reload? There does not seem to be a bug on this. Should I file one?
Yes, please do file a bug. Also, it would be interesting to know how long it takes to load a very simple page (e.g. google) after loading this test case. (In other words, is the teardown of the document what's expensive...)
Marking verified per last comments.
Bug 83721 filed on shift-reload 'problem'