Closed Bug 74888 Opened 24 years ago Closed 22 years ago

Mozilla is VERY slow on a large table

Categories

(Core :: Layout, defect)

Product:
Core
Component:
Layout
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 54542
Milestone:
Future

People

(Reporter: jens-uwe, Assigned: waterson)

References

(
URL
)

Details

(Keywords: memory-footprint, perf, testcase)

From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14 i686; en-US; 0.8.1) BuildID: 2001040221 the page is mainly a very long table (all products of a shop). Mozilla needs a VERY long time to render this table (it was not finished several minutes after I started to load this page). Mozilla is completly blocked during this time, so a user might think Mozilla crashed. Reproducible: Always Steps to Reproduce: 1. go to http://www.eteque.de/pricelist.php 2. be patient if you want to see the page... Actual Results: Mozilla needs ages to render the page (we are talking about several minutes here!) Expected Results: it should be rendered within very few seconds
I have a typo in the "how to reproduce" part. its the same URL as in the header, which is http://http://www.eteque.de/pricelist.php3 (php3 instead of php)
Correct, it could be faster. On the Mac, Moz takes 40 seconds to open the page (although, thanks to incremental reflow, you can display the beginning) while IE takes less than 10 seconds (but you can't see anything while it's working).
URL: http://http://www.eteque.de/pricelist... → http://www.eteque.de/pricelist.php3
Keywords: perf
Target Milestone: --- → mozilla1.0
*** Bug 84166 has been marked as a duplicate of this bug. ***
removing CC ( Jacek Piskozub : why CC you me on this bug ?)
BTW, isn't this bug a dup of bug 54542?
This _may_ be a duplicate of 54542; someone should profile this with a post-hyatt-checkin build. Even my post-hyatt debug build is REALLY slow on this page (vastly slower than ns4.x; it's been running for 5 minutes with no sign of finishing; I hate to think what it was like before). This might be some other form of O(N log(N)) or O(N*N) problem. Note: this page is a 1.1 MB table of: <HTML> <BODY BACKGROUND="./gif/test3.gif" > <FONT FACE="Helvetica"> <FORM action="/pricelist.php3" method=post><input type=hidden name="warengruppe" value=""><input type=hidden name="Wgtyp" value=""> <CENTER><FONT size=5></FONT></CENTER><BR> <CENTER> <table border=1 cellpadding=3 bgcolor=#CCCCCC bordercolor=#333333 > <tr> <th>Stk. <th>Artnr. <th>Artikel <th align=right><font color="#000000">Preis</font> <th>Info </th></tr> ... <tr> <td><input size=2 maxlength=2 name="Pos14" value="0"><input type=hidden name="Art14" value="15713"></td> <td>15713</td> <td> Varta Mignon 4er</td> <td align=right>8.00 DM</td> <td><img src="./button/ohnei2.gif"></td> </td></tr> [ repeat row with minor differences a ~3500 times ] ....
Also, a fresh startup of mozilla (debug build from today) and attempt to display that page is using 133MB of VM (119MB resident), and used 12 minuites CPU to layout the page. The memory usage seems to be constant at this point. Adding footprint. ns4.7 (linux) was using 100MB VM, and that was with 10 windows open for the last week - I guess the usage was over 70MB before I tried to go to that page with ns4.7.
Keywords: footprint
IE 5.x one a 233MHz MMX: 40 seconds. with Mozilla daily (opt): who knows; gave up after 10 minutes (same Win32 system)
Another issue with very large HTML pages (in addition to layout time) is UI unresponsiveness for 5-20 seconds at a time. See also the bug duped to this one (bug 84166)
Another example that exhibits the problem: http://www.teltarif.de/db/fein.html 1) slow loading time 2) Mozilla's RSS goes up to nearly 100 MB3) scrolling is slow and keeps on going for some time after key release (when scrolling with PgDn key) 4) Note the long time it takes to get the right-click context menu in that frame 5) select view source for above URL, 100% cpu load, UI *very slow* (might be a different bug/reason There's some JS in the page, but I always brose with JS disabled ...
*** Bug 93215 has been marked as a duplicate of this bug. ***
Blocks: 54542
I randomly broke the debugger when loading the url and generally saw the following stack. I didn't check to see if the frame model was being thrown away. -->waterson,attinasi nsContainerFrame::PositionFrameView(nsIPresContext * 0x045b8ac0, nsIFrame * 0x05af9860) line 396 nsContainerFrame::PositionChildViews(nsIPresContext * 0x045b8ac0, nsIFrame * 0x05af9794) line 778 + 13 bytes nsContainerFrame::PositionChildViews(nsIPresContext * 0x045b8ac0, nsIFrame * 0x05af9528) line 779 + 13 bytes nsContainerFrame::PositionChildViews(nsIPresContext * 0x045b8ac0, nsIFrame * 0x05af94d8) line 779 + 13 bytes nsContainerFrame::PositionChildViews(nsIPresContext * 0x045b8ac0, nsIFrame * 0x05af947c) line 779 + 13 bytes nsContainerFrame::PositionChildViews(nsIPresContext * 0x045b8ac0, nsIFrame * 0x05af418c) line 779 + 13 bytes nsContainerFrame::PositionChildViews(nsIPresContext * 0x045b8ac0, nsIFrame * 0x048277b4) line 779 + 13 bytes nsContainerFrame::PositionChildViews(nsIPresContext * 0x045b8ac0, nsIFrame * 0x048275c0) line 779 + 13 bytes nsContainerFrame::PositionChildViews(nsIPresContext * 0x045b8ac0, nsIFrame * 0x048bbb78) line 779 + 13 bytes nsContainerFrame::PositionChildViews(nsIPresContext * 0x045b8ac0, nsIFrame * 0x04827170) line 779 + 13 bytes nsContainerFrame::PositionChildViews(nsIPresContext * 0x045b8ac0, nsIFrame * 0x02ca9e90) line 779 + 13 bytes PlaceFrameView(nsIPresContext * 0x045b8ac0, nsIFrame * 0x02ca9e90) line 2679 + 13 bytes nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2214 + 19 bytes nsBlockFrame::Reflow(nsBlockFrame * const 0x02ca9e90, nsIPresContext * 0x045b8ac0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 824 + 15 bytes nsBlockReflowContext::DoReflowBlock(nsHTMLReflowState & {...}, nsReflowReason eReflowReason_Incremental, nsIFrame * 0x02ca9e90, const nsRect & {x=0 y=0 width=10395 height=1073741824}, int 1, nsCollapsingMargin & {...}, int 1, nsMargin & {top=0 right=0 bottom=0 left=0}, unsigned int & 0) line 580 + 36 bytes nsBlockReflowContext::ReflowBlock(nsIFrame * 0x02ca9e90, const nsRect & {x=0 y=0 width=10395 height=1073741824}, int 1, nsCollapsingMargin & {...}, int 1, nsMargin & {top=0 right=0 bottom=0 left=0}, unsigned int & 0) line 356 + 50 bytes nsBlockFrame::ReflowBlockFrame(nsBlockReflowState & {...}, nsLineList_iterator {...}, int * 0x0012eae4) line 3168 + 59 bytes nsBlockFrame::ReflowLine(nsBlockReflowState & {...}, nsLineList_iterator {...}, int * 0x0012eae4, int 0) line 2367 + 27 bytes nsBlockFrame::ReflowDirtyLines(nsBlockReflowState & {...}) line 2149 + 31 bytes nsBlockFrame::Reflow(nsBlockFrame * const 0x02ca9b40, nsIPresContext * 0x045b8ac0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 824 + 15 bytes nsContainerFrame::ReflowChild(nsIFrame * 0x02ca9b40, nsIPresContext * 0x045b8ac0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 714 + 31 bytes CanvasFrame::Reflow(CanvasFrame * const 0x048bb19c, nsIPresContext * 0x045b8ac0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 567 nsBoxToBlockAdaptor::Reflow(nsBoxLayoutState & {...}, nsIPresContext * 0x045b8ac0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0, int 0, int 0, int 10395, int 8745, int 1) line 882 nsBoxToBlockAdaptor::DoLayout(nsBoxToBlockAdaptor * const 0x02ca9aa0, nsBoxLayoutState & {...}) line 538 + 52 bytes nsBox::Layout(nsBox * const 0x02ca9aa0, nsBoxLayoutState & {...}) line 1002 nsScrollBoxFrame::DoLayout(nsScrollBoxFrame * const 0x048bb54c, nsBoxLayoutState & {...}) line 392 nsBox::Layout(nsBox * const 0x048bb54c, nsBoxLayoutState & {...}) line 1002 nsContainerBox::LayoutChildAt(nsBoxLayoutState & {...}, nsIBox * 0x048bb54c, const nsRect & {x=0 y=0 width=10395 height=8745}) line 649 + 16 bytes nsGfxScrollFrameInner::LayoutBox(nsBoxLayoutState & {...}, nsIBox * 0x048bb54c, const nsRect & {x=0 y=0 width=10395 height=8745}) line 1026 + 17 bytes nsGfxScrollFrameInner::Layout(nsBoxLayoutState & {...}) line 1133 nsGfxScrollFrame::DoLayout(nsGfxScrollFrame * const 0x048bb2e4, nsBoxLayoutState & {...}) line 1034 + 15 bytes nsBox::Layout(nsBox * const 0x048bb2e4, nsBoxLayoutState & {...}) line 1002 nsBoxFrame::Reflow(nsBoxFrame * const 0x048bb2ac, nsIPresContext * 0x045b8ac0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 928 nsGfxScrollFrame::Reflow(nsGfxScrollFrame * const 0x048bb2ac, nsIPresContext * 0x045b8ac0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 750 + 25 bytes nsContainerFrame::ReflowChild(nsIFrame * 0x048bb2ac, nsIPresContext * 0x045b8ac0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, int 0, int 0, unsigned int 0, unsigned int & 0) line 714 + 31 bytes ViewportFrame::Reflow(ViewportFrame * const 0x048bb160, nsIPresContext * 0x045b8ac0, nsHTMLReflowMetrics & {...}, const nsHTMLReflowState & {...}, unsigned int & 0) line 576 nsHTMLReflowCommand::Dispatch(nsHTMLReflowCommand * const 0x06713470, nsIPresContext * 0x045b8ac0, nsHTMLReflowMetrics & {...}, const nsSize & {width=10650 height=8745}, nsIRenderingContext & {...}) line 217 PresShell::ProcessReflowCommand(nsVoidArray & {...}, int 1, nsHTMLReflowMetrics & {...}, nsSize & {width=10650 height=8745}, nsIRenderingContext & {...}) line 6017 PresShell::ProcessReflowCommands(int 1) line 6072 ReflowEvent::HandleEvent() line 5928 HandlePLEvent(ReflowEvent * 0x06851cc0) line 5942 PL_HandleEvent(PLEvent * 0x06851cc0) line 590 + 10 bytes PL_ProcessPendingEvents(PLEventQueue * 0x004fffd0) line 520 + 9 bytes _md_EventReceiverProc(HWND__ * 0x003d0754, unsigned int 49525, unsigned int 0, long 5242832) line 1071 + 9 bytes USER32! 77e12e98() USER32! 77e130e0() USER32! 77e15824() nsAppShellService::Run(nsAppShellService * const 0x005385d0) line 303 main1(int 1, char * * 0x00480030, nsISupports * 0x00000000) line 1304 + 32 bytes main(int 1, char * * 0x00480030) line 1630 + 37 bytes mainCRTStartup() line 338 + 17 bytes
Assignee: karnaze → waterson
Blocks: 103670
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0 → mozilla0.9.7
Target Milestone: mozilla0.9.7 → mozilla0.9.8
I did a quantify run of a similar table and got the following results: There probably were ~23000 frames/views in my testcase because there were 23495 calls to PlaceFrameView doing the same number of calls to nsContainerFrame::PositionChildViews. But then PositionChildViews called itself recursively causing 120330162 calls to itself. Thats 120 millions! I don't know what the frame tree looks like, but it's obviously some kind of O(n^2) algorithm in there, with every frame in some way traversing its frame tree.
Target Milestone: mozilla0.9.8 → Future
Yet another URL showing the same problem: http://www.sciam.com/news/ Netscape 4.77 on Linux and IE 5.5 on Win98 have no problem with this page on my system (Pentium II 266 MHz), Mozilla takes forever. I ran this page through the HTML validator at http://validator.w3.org/ and got a ton of error messages, so the HTML of the page itself is pretty buggy. But the browser should either give up or render it in a reasonable time, consuming enormous amounts of CPU time is not acceptable. I cleaned up the HTML source myself by taking out most of the junk (mostly javascript), but this made no difference. The trouble must lie with the large table in the page.
http://www.sciam.com/news/ is bug 84466 and I believe that it is not related to this bug at all.
All the testcases here have reasonable performance for me using Phoenix 20021020 on Win2K.
Here is the testcase URL http://www.heise.de/ix/browser/tables/index.php? what=text&my_trlimit=8000&my_tdlimit=6 trlimit and tdlimit can be adjusted.
http://www.eteque.de/pricelist.php3 is a broken CGI now. http://www.teltarif.de/db/fein.html loads pretty fast for me.... Is this still a problem?
the testcase in comment #18 are really fine & easy customizable. beside other testcases in bug 54542 there is one at http://bugzilla.mozilla.org/show_bug.cgi?id=54542#c137 which also has a profile.
Well, if this is all covered by bug 54542, then.... *** This bug has been marked as a duplicate of 54542 ***
No longer blocks: 54542
Status: ASSIGNED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.