20485 - Slow load time and 100% cpu utilization with large table-based pages

Status: VERIFIED FIXED

(Core :: Layout: Tables, defect, P3)

Description

[skoll]

The site http://www.voodooextreme.com takes 199 seconds (over 3 minutes) to
fully load, using 100% cpu the whole while.  Other browsers (IE and NS) take 40
seconds, so it's a slow page to begin with, but they don't use 100% cpu.

STEPS TO REPRODUCE: Load http://www.voodooextreme.com

ACTUAL RESULTS:  Extremely slow load time, using 100% CPU

EXPECTED RESULTS: Load time on par with other browsers, and definitely shouldn't
pin the CPU.

VERSION TESTED: Win32 1999-12-03-02 on a P2-300 running NT4 with a DSL net
connection (net speed isn't the issue here, since other browsers are
significantly faster).

[e-mail] felt this bug might not be a dupe of 14961 despite the similar
symptoms.

Comment 1

[rickg]

Vidur -- this may be related 17325.

Comment 2

[skoll]

Oops, the version I discovered this bug with was actually 1999-12-01-02
(December 1st).  There is a typo in my initial description.

Comment 3

[Simon Fraser [no longer active]]

This page is an excellent test case for the reflow notifcation problem.

Comment 4

[Simon Fraser [no longer active]]

This page is an excellent test case for the reflow notifcation problem. On Mac,

loading this page prevented me using my machine for about 2 minutes.

Comment 5

[John Morrison]

Just to note one thing (in addition to this being a huge, deeply nested table).
The HTML contains a variable number (as high as 90+) of these fragments:

  <script language="JavaScript">
  <!--
  stime("1:24 AM");
  //-->
  </script>

where 'stime(str)' calculates a time value and does document.write of 'hh:mm
?M (your time)'

If you _remove_ these <script> calls, that is, the minutes-long 100% CPU does
not happen (at least not in my tests) -- i.e., this page is still slow, but no
worse than slashdot or my.netscape.com (using Nov 27 WinNT opt build).

Comment 6

[rubydoo123]

I just tried this on win95, using the commercial build from 1999120308 and the
first time, the app hung and I had to use ctrl-alt-delete. So I tried it again
-- after 3 minutes, my system locked up, and once again I had to
ctrl+alt+delete.

Comment 7

[Simon Fraser [no longer active]]

Moving to HTMLTable, reassigning to karnaze.

The problem here is with HTML table rendering. If I make a simple, long document
with just text in <p>s, then loading speed is reasonable (and each content
appended takes around the same amount of time).

Enclose the entire document in a one-cell table, and loading suddenly becomes an
order of magnitude slower, and each content appended-reflow becomes order N,
where N is the number of <p>s in the table cell.

The url this bug was filed on is a particularly harsh example, because the bulk
of the page is in a single table cell, and contains over 80 <p>, which script
tags that do a document.writeln, and lots of small images.

Comment 8

[vidur (gone)]

The <SCRIPT> elements in the original page force a notification. Removing them
decreases the number of notifications and, as Simon pointed out, this reduces
load time.

Comment 9

[karnaze (gone)]

Adding keywords incremental reflow.

Comment 10

[troy]

*** Bug 23218 has been marked as a duplicate of this bug. ***

Comment 11

[troy]

We fixed table incremental reflow to do a single reflow (and not the three
reflows it was doing), and this has helped considerably.

The remaining issue is that the content sink is flushing when it sees a SCRIPT
tag.

Vidur is working on this issue, so re-assigning the bug

Comment 12

[vidur (gone)]

OK, we're doing a lot better - at least in terms of content sink notifications. 
After my checkin on 1/28/2000 (content sink doesn't automatically flush on 
SCRIPT elements) we're doing fewer notifications from the sink. With some of 
Troy's changes, I believe we are comparable to Nav 4.x loading of the page. It's 
hard to be exact, though - the site itself is slow and flaky.

Comment 13

[leger]

Just test http://www.voodooextreme.com on 4.72 RTM vs todays Win32 2000021509 
with my handy stop watch.  27:27 sec load time on 4.72, 30:39 on mozilla.  Not 
bad for moailla.  Rough page, lots happening to load.  Marking this bug 
Verified.