I came across this problem when viewing automatically generated HTML. The page is similar to tinderbox output, except it is much larger. Trying to display this will lock mozilla up for several minutes. I've jprofed the problem, and its down in the layout code. IE also takes a while to render this page, but it is at least an order of magnitude faster than firefox. This isn't a new bug. It happes with seamonkey, firefox 1.0X, 1.5, & 1.6a

>I've jprofed could you please attach the jprof to the bug.

I've got a snag here. I no longer have the original jprof, I did it several months ago. I attempted to generate a new one. However, I have switch to Fedora FC4 since then, and that seems to break jprof. It appears that the jprof stack walking code crashes when it is called on a thread (other than the main thread). I am going to attempt to fix jprof. In the mean time, if someone could generate a jprof for this testcase, I would appreciate it.

Boris could run a jprof on this?

Note that the actual HTML here is about 12MB... :( I only profiled part of the pageload; I didn't wait for it to finish. Salient points from the profile: Total hit count: 4412078 Count %Total Function Name 636158 14.4 nsCellMap::GetDataAt(nsTableCellMap&, int, int, int) 246354 5.6 sem_unlink 233866 5.3 __libc_calloc 132498 3.0 nsCellMap::GetRowSpan(nsTableCellMap&, int, int, int, int&) 129147 2.9 nsStyleContext::GetStyleData(nsStyleStructID) 99942 2.3 nsCellMap::RebuildConsideringRows(nsTableCellMap&, int, nsVoidArray*, int, nsRect&) 87533 2.0 nsRuleNode::GetStyleData(nsStyleStructID, nsStyleContext*, int) Looking from top down, we have 3241194 hits under PresShell::ProcessReflowCommands. Of those, 2569616 are under IncrementalReflow::Dispatch and reflow in general. The rest are under frame construction. In particular, we have (all told) 1379272 hits under nsTableRowGroupFrame::AppendFrames. This goes through nsTableFrame::InsertRows and pretty much all ends up in nsCellMap::RebuildConsideringRows. This last breaks down as: 64798 99942 1346905 nsCellMap::RebuildConsideringRows(nsTableCellMap&, int, nsVoidArray*, int, nsRect&) 812579 nsCellMap::AppendCell(nsTableCellMap&, nsTableCellFrame*, int, int, nsRect&, int*) 223646 operator delete(void*) 90758 nsCellMap::Grow(nsTableCellMap&, int, int) 67522 operator delete[](void*) 26529 nsVoidArray::~nsVoidArray() 4847 nsCellMap::GetDataAt(nsTableCellMap&, int, int, int) 3854 operator new(unsigned) 3465 CellData::CellData(nsTableCellFrame*) This whole thing looks like lots of our other "large page" bugs -- trying to be incremental is making our pageload O(N^2) in page size.

Thanks Boris. FWIW, IE handles this page much better, I don't know if it does incremental page loads or not.

It more or less stops being incremental once it's showing you a pageful of stuff, iirc.

blocking flag on a performance bug??? If a reduced testcase can be created so that one reasonable work on this, this might be worth it, otherwise this is for me future.

Here is a smaller version of the testcase

is this worth a minus on blocking 1.9a1, and investigating further once the Reflow Branch lands?

Dunno that the reflow branch will have any effect on this -- we're trying to not change table reflow stuff.

Still see this on Fx 3.6.4.

On which testcase? The first one or the second one? I just did a profile of the second one and there are no obvious hotspots.... That said the RebuildConsideringRows is still there (at about 5% of the total testcase). I wonder whether we could do the cellmap rebuilds lazily or something, or avoid them altogether....

(In reply to comment #14) > On which testcase? The first one or the second one? > The first one. The second one, the smaller one, works fine here.

OK, on the first testcase we take about 20s to load the page over here on trunk (vs 7s for webkit and 5+ minutes for Opera, till I killed it, on the same hardware). Around 25% of the time is invalidation; bug 539356 will help there. 5% is spent constructing new frames. The rest is spent reflowing, off both the refresh driver and painting. So we're doing 2x the work we need to, in a sense. Bug 598482 and bug 374980 might help with that. Past that, there are no obvious hotspots, other than "table reflow is complicated"... We should reprofile once those three bugs are fixed.