Closed Bug 54542 Opened 24 years ago Closed 13 years ago

Large tables are slow

Categories

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

Product:
Core
Component:
Layout: Tables
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Milestone:
Future

People

(Reporter: jesup, Unassigned)

References

(Depends on 3 open bugs, Blocks 1 open bug,
URL
)

Details

(4 keywords)

Attachments

(9 files, 1 obsolete file)

Testcase array of input fields
28.49 KB, text/html
Details
Patch that halves the number of non-pseudo style resolutions.
1.06 KB, patch
Details | Diff | Splinter Review
jprof of ct table from bug 110251
596.27 KB, text/html
Details
jprof of wbtblclr.html
378.32 KB, text/html
Details
jprof of wbtbltxt.html
311.40 KB, text/html
Details
Top20 function measured by quantify on solaris
1.58 KB, text/plain
Details
Testcase with large table
192.46 KB, application/x-zip-compressed
Details
hasmorethanonecell shifted to cellmap
9.27 KB, patch
Details | Diff | Splinter Review
Testcase with drop-down menus
181.60 KB, text/html
Details 
FreeBSD 4.1 20000927xx and Win32 2000092804

Sometime in the last few weeks incremental reflow in large tables has gotten
much worse.  Also, the positions of the elements are different depending on in
which reflow they were places, I believe.  In the example given, the table takes
a long time to format (and reflows several times), and different rows end up
slightly differently laid out -- the text widgets are a few pixels left or
right, which looks really strange in a regular array).  This same page used to
render both fast asn correctly in M17 or shortly thereafter.  I know some work
was done to re-enable incremental reflow (which certainly needed to be done); it
seems as if it needs some tuning for large tables.
Keywords: testcase
Reassigning to myself.
Assignee: clayton → karnaze
http://soros.ath.cx has even worse problems with this.  I've been at 100% CPU
load for probably 15 minutes and the images still aren't all displayed
(PIII-800).  Found the reference to this site on the performance newsgroup. 
Note that the problem with this site was reported before and was dup'd to 20110,
as a JS rollover bug.  20110 is now marked fixed.  However, this site has
massive problems in just doing layout before JS rollover gets involved.  Also,
the JS rollover problem still exists with this page it seems (though maybe it's
something else slowing response to rollover, like reflow).  I'm going to reopen
20110 also.

Something is VERY wrong.  We desparately need a profile done on the load of this
page.  Anyone care to help me on how to set up a profile?  I've done gprof
profiling before, any tricks I need to know about profiling in Mozilla?

Adding perf, helpwanted, upping severity.

Karnaze: any ideas?
Severity: normal → critical
Keywords: helpwanted, perf
If you check out the mozilla nglayout stress test cases
http://www.mozilla.org/newlayout/testcases/stress/wbtbltxt.html and
http://www.mozilla.org/newlayout/testcases/stress/wbtblclr.html
you'll see that performance is MUCH worse than ns4.7, and it used to be better
than ns4.7.  (By much worse I mean 4-10 times worse on large tables on the
second, ns4.7 takes 4 seconds to layout on a PIII-800, Mozilla takes 40
seconds!)

Nominating for RTM, though I suspect it's too late.
Keywords: regression, rtm
Summary: Incremental reflow is much slower/different on large tables → Incremental reflow is MUCH slower/different on large tables
This is probably due to the large number of form controls. Marking rtm- since 
PDT would not approve a fix right now. Adding MJudge to CC list.
Whiteboard: [rtm-]
I should note that while the original example has a large number of form
controls, the other two examples (from the nglayout stress tests on
mozilla.org!) have nothing but a 100x100 table with text (or text on a
background).  So the problem (10x slowdown vs ns4.7, which was slow to begin
with) is a general table problem, and it's also a regression - this was really
good in earlier releases (M16 I think).  I've seen it all over where there are
medium to large-sized tables.  Note that 40 seconds for the 100x100 colored
table is on a PIII-800!

Updated URL.  Renominating (removing rtm-) because I feel this is a true
STOP-SHIP bug.  A number of colleagues have been shown recent builds
side-by-side with ns4.7, showing these test cases and other real-world pages
they chose.  They were appalled at the performance on tables of form elements we
use for web-based control - ones that aren't that large, either - small enough
to be around a 1/4 screen.

I'm also going to post in porkjockeys about this bug.
URL: http://www.mozilla.org/newlayout/test...
Whiteboard: [rtm-]
I'm attaching the only patch I think might have a chance of getting into RTM.
It removes a redundant style resolution that was occurring.  This change yields
about a 25% speedup for tables that use background images and colors in their cells.


The 100x100 colored cell table test went from 23 seconds to 16 seconds with this
patch on my machine.


Just out of curiosity, how long did it take you to think of a solution to this 
problem and write a patch?
a=buster.  no-brainer for rtm
Removing redundant style resolution certainly will help (sounds like it did!),
but the fundamental problem applies to cells without backgrounds as well.  Also
it applies pretty nastily to tables full of form elements.

See the 100x100 example without colors, and the testcase attached to this bug.
Thanks for the attention to this one, guys!

Adding [rtm+]. Thanks Hyatt.
Whiteboard: [rmt+] a=buster, r=karnaze
Whiteboard: [rmt+] a=buster, r=karnaze → [rtm+] a=buster, r=karnaze
rtm++
Whiteboard: [rtm+] a=buster, r=karnaze → [rtm++] a=buster, r=karnaze
really ++
Christian, I spent about an hour this morning profiling the 100x100 color table 
loading using Quantify on Win32.
Whiteboard: [rtm++] a=buster, r=karnaze → [rtm++] a=buster, r=karnaze [patch checked in on branch]
Is anyone still working on this one?  Hyatt's patch (while a definite Good
Thing) is not enough to solve this problem.  I know he doesn't think any more
extensive patch will get approved, but table layout is still slower than ....
Slow enough that I believe than any reviewer will notice it, and if they happen
to run a machine from a year or two ago (say a 200MHz MMX), it will be PAINFULLY
slow on large numbers of pretty standard pages.  Remember also it appears to be
even worse when the table has form elements in it.

I'll apply Hyatt's patch and recheck timings.

I am not working on this bug (beyond checking in Hyatt's patch) for rtm, because 
PDT will not approve a fix. I'm sorry for not addressing it in early Oct., when 
it had a chance for approval.
Status: NEW → ASSIGNED
I am going back to previous builds to determine when the deterioration occurred.
I tested an M17 FreeBSD build that someone had around here: ~45 seconds for the
colored 100x100 table.  So the problem predates M17.  I think (please correct me
if I'm wrong) that for M16 reflow was disabled.  I thought it was reenabled
after M17, but maybe I was wrong.

Note also that I retested with a pull from 10/23 (trunk), and added the patch
here to it for the style contexts.  I'm now seeing 68 seconds for 100x100
colored, and 33 seconds for 100x100 uncolored.  This appears to be _worse_ than
it was a week or two ago (40 sec for 100x100 colored, and I think around 10,
maybe 15, for uncolored).
I see a definite improvement with the patch on Win32 (20-25%).  There's no 
way that patch would slow anything down.  Could you try a current build without 
the patch?

Here are my testing results so far:

(1)http://www.mozilla.org/newlayout/testcases/stress/wbtbltxt.html

Navigator: Loaded in 7.7 seconds
6/13 build: Loaded in 5.9 seconds
M17 release build (8/10): Loaded in 5.6 seconds
10/24 build: Loaded in 4.8 seconds 

(2) http://www.mozilla.org/newlayout/testcases/stress/wbtblclr.html

Navigator: Loaded in 9 seconds
6/13 build: Loaded in 11.9 seconds
M17 release build (8/10): Loaded in 11.14 seconds
10/24 build: Loaded in 6.25 seconds 

(3) http://soros.ath.cx

Navigator: Loaded in 1.1 minutes
6/13 build: Loaded in 4.5 minutes
M17 release build (8/10): couldn't get it to load - still trying
10/24 build: Loaded in 3.2 minutes

URL's (1) and (2) were loaded from my local computer; (3) from the server. In 
the first two examples, time in Netscape6 is better than Nav. Example (3) shows 
deterioration from Nav, but getting progressively better in Netscape6. I can 
continue to go back and test example (3) on builds previous to 6/13 if this is 
relevant. Please advise.
QA Contact: petersen → chrisd
10/24 build used above was 'branch' build.
Chris: machine, OS, CPU speed?  Thanks for the testing!  Until now I'd only seen
numbers from myself, Soros, and Hyatt.

Removed the patch, killed and restarted.  New numbers:
Colored: 70 seconds
Plain:   34 seconds

Within timing error those are the same as without the patch, and close to twice
as slow as they were 10 days ago. 

I note that Chris' numbers are MUCH closer to navigator (ns4.7 I assume?) than
mine are.  I'm doing a fresh rebuild with an update to some build options.  I
should note that the Win32 2000101221 daily I tested seemed to have the same
problem as I have in my FreeBSD builds.  Are dailies debug builds or not?  I
assumed not.  I'm doing a clobber build to ensure that there's no debug code in
- I had assumed that any debug code would not have a giant effect on the
timings, and I don't usually run disable-debug (and don't have disk space to
keep both around).  Mea culpa; if this was the cause then I'm very annoyed at
myself for forgetting this.  The performance was so bad that I never thought it
could be something as simple as debug code, and Win32 dailies showed similar
problems.  I think there _was_ a problem with the colored table (fixed by hyatt)
- Chris' numbers show a 50% reduction in time.

If Chris' numbers hold up, then this may no longer be an issue (post hyatt's
patch).  And in this case, please excuse the egg on my face and the time people
have spent on it (though hyatt's patch is a Good Thing I believe).

Ok, I did a clobber build with no debugging (and without Hyatt's patch).  Times:
Colored: 41 seconds
Plain: 21 seconds

So, while debug certainly makes a difference, it's not the problem I was seeing.
For reference the ns4.7 numbers I see are:
Colored: 6 seconds
Plain: 5 seconds

I'll throw Hyatt's patch back in and try again.
Optimized, with hyatt's patch:
Colored: 37 seconds
Plain: 17.5 seconds.

A little better (on the order of 10% for colored, 20% for plain), but still way
worse than ns4.7.

I wonder is this might be a difference between Win32 builds and Linux/FreeBSD
builds?  The event models are somewhat different, this _could_ interact with the
layout vs. draw vs. reflow dynamics.

More times:
233MHz MMX Win95
mozilla without hyatt's patch:
	See newsgroup from yesterday - I think they were ~70sec and ~35 sec

ns4.7:
	Colored: 25 sec
	Plain: 21 sec

ie5.5:
	Colored: 4 sec
	Plain: 3 sec

Worldgate Gazelle (spyglass 3.2-based) on a 450MHz PIII:
	Colored: 1 sec including parsing (hard to measure)
	Plain: 1 sec including parsing (hard to measure)

This reinforces that there's a difference between Linux/FreeBSD and Win32
versions of Mozilla.
My numbers, from a 866MHz p3 running linux.  mozilla built "--disable-debug
--enable-optimize" from a 10/24 morning cvs pull.

file:/u/tor/wbtblclr.html

netscape 4.73   10 sec
mozilla         18 sec
mozilla+hyatt   17 sec

file:/u/tor/wbtbltxt.html

netscape 4.73   9 sec
mozilla         5 sec
mozilla+hyatt   5 sec

I'm running Win98 on a Dell 500Mhz P3
Aha (maybe).  I --disable-debugged, but I didn't realize I needed to 
--enable-optimize.  It seems to make quite a difference in this case.  tor's 
results seem to indicate that mozilla is about 2x ns4.x on color, about 1/2 
ns4.x on plain.  My results with the Win95 daily from 10/12 indicated that both 
colored and plain were about 2-3x the ns4.x times.  How are the dailies built?

I'll recheck one more time tomorrow morning (I'm home now).

I still wouldn't call parity with ns4.x on layout speed to be a significant win 
- witness the Win95 times I posted for ns4.x/ie/spyglass.  We're still vastly 
slower than ie on layout.  (IE5 is about 5-8 times faster than ns4.x on these 
tables).

Thanks for all the help everyone.

By the way, my original numbers were off for the color test (did not let the 
page fully load as I discovered because scrollbars were not completely 
operational). After running again, my color test is VERY close 
to tor@cs.brown.edu. Will try with new build also tomorrow. The problem remains 
with the soros site which is dramatically slower in Netscape6.
I'm pretty sure the soros site is a different problem related to how
notifications for the images loading are filtering through libimg and
the layout system.  It would be great if someone with quantify could
grab a profile of http://soros.ath.cx/ to verify or disprove this.

Changing rtm++ to rtm- to get it off the radar. Hyatt's patch has been checked 
into the branch and trunk.
Whiteboard: [rtm++] a=buster, r=karnaze [patch checked in on branch] → [rtm-] [was ++] a=buster, r=karnaze
With --enable-optimize:
Colored:  23 seconds
Plain:    10 seconds

These are compared to 6 and 5 seconds for ns4.7.

Using 10/25 commercial build on Win 98, I concur with the times on Netscape 
6 stated above: 
Colored:  23 seconds
Plain:    10 seconds

but I get closer to 10 seconds on ns4.7 for Colored page to load.
Chris: I'm on a PIII-800 with 512MB; you're on a PII-500.  I'm not surprised
that I see ~6 seconds for ns4.7 for the colored table and you see 10.  I am
surprised that for you Mozilla is laying them out as fast as it is for me, but
Akkana and others believe that mozilla is generally slow on Unix currently
(people are saying it runs faster under the WINE Win32 emulator in Linux than
the native Linux version runs)

Thanks again for the testing.  I think this bug should remain open, because even
if we're close to ns4.7 times (and I still see 4x worse than ns4.7), ns4.7 is
DOG SLOW on complex pages.  Witness IE5 handling these in 3-4 seconds on a MUCH
slower machine (ns4.7 was >20), and another browser doing it in less than 1
second.

I'm suggest changing the bug summary to "Performance problems laying out complex
pages" or some such.
clearing out the whiteboard noise, and adding some observations from quantify on
wbtbltxt.html in viewer.

Breaking down the individual processes, here's a table that shows each
process' cost as a percent of the overall process time (filtering out some
obvious overhead, and understanding that the percent measurement is just a
relative value that includes lots of overhead that doesn't translate to page
loading), and the F+D % of the method I used as a proxy for the process:

PROCESS             F+D%  F+D(sec) Count Method
------------------------------------------------------------------------------
reflow             1.33%  .91       20   ViewportFrame::Reflow
frame construction 1.39%  .95       24   nsCSSFrameConstructor::ContentAppended
style resolution    .51%  .75   40,459   StyleSetImpl::ResolveStyleFor
 (2 methods total)                     + StyleSetImpl::ResolvePseudoStyleFor

I think there's 30,330 frames created
(looking at FrameManager::NotifyDestroyingFrame)

hyatt and waterson asserted in the news groups that
CSSRuleProcessor::RulesMatching() was part of the problem.  For the above case,
here's the cost of RulesMatching

RulesMatching      F+D%   F+D(sec)  Count
Normal              .30%    .20     20,251
Pseudo              .18%    .13     70,464

So what's most interesting here is the F+D of the Pseudo RulesMatching method is
~17% of the total style resolution time. This makes it approximately 5% of the
total initial page layout time (frame construction + style resolution + layout).
 This ignores parsing and content creation, adding them in extrapolated from
bindu's raptor performance numbers means that pseudo RulesMatching is roughly 3%
of the total initial layout cost for this document.

Marc pointed out to me that he knows pseudo RulesMatching is a performance
issue, and that it's tied to several other performance tasks he has on his
plate.  So, I suggest he submit a separate bug on that issue, and we use this
bug to cover things specific to html tables.
Priority: P3 → P2
Whiteboard: [rtm-] [was ++] a=buster, r=karnaze
Some numbers more relevant to table layout:
* We make 1,542,422 calls to nsCellMap::GetMapCellAt() which costs us 0.11 sec
(F+D) time.  This is a huge number of calls for a 10,000 cell table (15 calls
per cell.)  .08 of the .11 seconds is spent in the method itself, so it's doing
something very expensive.  The rest of the time is spent in
nsVoidArray::ElementAt().

* We also make 334200 calls to nsCellMap::GetCellInfoAt() at a cost of 98ms.
That seems way too high.

* 15 calls to nsTableFrame::AdjustForCollapsingCols() takes 93.34ms.  That seems
rather expensive for a method that should very rarely have any effect.
According to quantify, it looks like it's ***always*** allocating a frame
property.  If every cell needs the value, it shouldn't be a frame property,
that's way to expensive.  I suspect it's an error that these things are getting
allocated at all.  AdjustForCollapsingRows seems to be much better, taking only
.16ms.

* We are making 66,800 calls to nsTableCellFrame::VerticallyAlignChild() costing
us 40ms.  That seems like way too many calls for a 10000 cell table.  Maybe
there are some optimizations in there that shortcut any real work in those
calls, because the total time is only about 40ms.

* I see 20,104 calls to ResolveStyleContext from
nsCSSFrameConstructor::TableProcessChild().  I thought Hyatt fixed this already?





Steve, pardon my ignorance, but what does "F+D" mean?


F+D = "Function + Descendents"
This is the time taken by the function itself, plus all subroutines it calls.
In terms of measuring the cost of a method, it's what you usually care about.
OK, so why are you focusing on code that seems to be taking 3-4% of the 
execution time?
Marking mozilla0.9.
Target Milestone: --- → mozilla0.9
adding to nsbeta1 radar.  I think we had a patch here
that PDT latered for 6.0?
Keywords: nsbeta1
I should note that while there's a patch that helps a few things here, and some
commentary about how to reduce redundant calls for a few things amounting to
maybe 5% of the time, the basic problem (being VASTLY slower laying out complex
pages than IE or other browsers, and at best being close to as fast as ns4.7)
still exists and there's no real solution or understanding of.
See comments in bug 60494 for incremental table reflow optimizations that are
planned. The patch in bug 60494 may even help this bug.
*** Bug 57265 has been marked as a duplicate of this bug. ***
As noted in bug 67692, I tested this today (debug build) and timing has gone up
to 2:40 for wbtblclr.  Note that the style changes recently might have added
more debug-only tests, so it needs to be retested with an optimized no-debug
build.  Still, it looks like a significant regression in the last 2 months.
Retested FreeBSD 4.1 20010206xx

Full optimize/no DEBUG build

For wbtblclr on a PIII-800, time is 1:40 (100 seconds)!
This is on the order of 5 times as bad as M18/NS6 was.


For wbtbltxt, time is 14 seconds.  This is only 40-50% worse than M18.
For reference again, NS4.75 on this same page is circa 6-7 seconds for either
color or plain(!)

Netscape's standard compliance QA team reorganised itself once again, so taking 
remaining non-tables style bugs. Sorry about the spam. I tried to get this done 
directly at the database level, but apparently that is "not easy because of the 
shadow db", "plus it screws up the audit trail", so no can do...
QA Contact: chrisd → ian
Moving to mozilla0.8.1
Target Milestone: mozilla0.9 → mozilla0.8.1
Well, the problem on http://soros.ath.cx/  has been solved with this
morning's build (on linux at least) .. page loads were exceeding 700
seconds in recent days, but things have turned around for the better...
Not only does the page layout in under a minute (which is faster than
was IE does it), the mouseovers actually work and they are very
responsive, very responsive. I'm very impressed... I did have a bounty
on the bug ( 108 bottles of canadian beer ), so if anybody can determine
who landed the fixer, I need to speak with them.  

Check Bug 20110 duplication.

Robert Soros.
robert@soros.ath.cx
http://soros.ath.cx
Well, one suspect are attinasi:
"Don't reflow for every notification of an image load if the image frame's size
is constrained. b=69552 r=kmcclusk sr=hyatt"

Yes, I bet it is the image reflow optimization. If the page has any GIF images
it can make a HUGE difference. I'll investigate the page in question when I have
a chance (that bounty is motivating!). If somebody else wants to compare with
and without my changes, just comment out the new code, as in the following block
in nsImageFrame.cpp:

/*if(!mSizeConstrained) mSizeConstrained is the bullet here (set in Reflow)! */ {
  if (mParent) {
    mState |= NS_FRAME_IS_DIRTY;
	  mParent->ReflowDirtyChild(presShell, (nsIFrame*) this);
  }
  else {
    NS_ASSERTION(0, "No parent to pass the reflow request up to.");
  }


I looked at the soros page, and even though it does not use GIFs I can see how
this change would make a huge difference. Because the width and height are
specified for the ten-bazillion images, they do not need to each be reflowed
when they complete loading. In GIF images this was worse because they were often
animated and caused a reflow on every image-pane (even single image
animations!), but when you have a boat-load of constrained images the
optimization will really help alot even if non-animated.
soros.ath.cx is now circa 9 seconds to display on my system (after I've been to
it once to cache the images).  Great job, mark! This should really help a lot.

The change doesn't seem to help with either wbtbltxt or wbtblclr, unfortunately.
(Not surprising, as they have no images.)  They appear to be table-layout-reflow
problems - I know someone is/was going to make some similar changes in the table
code to squash unneeded reflows.
Karnaze has that pretty much ready to go. In fact, I'm up to my ears reviewing
the changes now. Viva Karnaze!!!
Blocks: 71668
Moving to mozilla0.9
Target Milestone: mozilla0.8.1 → mozilla0.9
I am closing this bug. On my 450MHZ PII, Nav4.7 loaded wbtbltxt.html in ~8sec 
Mozilla (Viewer) loaded it in ~9sec. wbtblclr is handled in bug 67692. Nav4.7 
loaded attachment #1 [details] [diff] [review] in under 3sec and Viewer loaded it in ~3sec (Viewer never 
changed the cursor after the page load, which is probably another bug).
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Please see my notes on bug 67692 (which was a spin-off of this bug). 

Measurements today with a optimized (but debug-enabled!) build show that we're
still 2-5 times slower than ns4.75; about the same speed we were before the
regression - which was still way slow.  IE5.5 takes <1 second for either on a
PIII/650, and a spyglass-based browser I work on takes <<1 second.  I'm doing an
optimized no-debug build, and will re-test with that to verify tomorrow (I'm
sick and going home).  If the numbers are around what I just measured, I plan to
reopen this.


optimized, no-debug numbers:
text: 10 seconds (vs 6 for ns4.7)
color: 24 seconds (vs 7 for ns4.7)

PIII/800, FreeBSD4.1, mozilla pull/build 20010319xx  --enable-optimize
--disable-debug --disable-cpp-rtti --disable-pedantic --disable-mailnews
--with-pthreads

Reopening.  We're still 3.5x slower on color, 1.6x slower on text.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Randell, wbtblclr is handled in bug 67692. Please, do not mention that example 
again in this bug.

I am closing this bug again, because your results on wbtbltxt do not jive with 
mine. If you feel this bug needs to be reopened then please do the following - 
(1) make sure that you are compiling without any debugging or profiling. (2) 
make sure that you have enough main memory so that no swapping is occuring, (3) 
load wbtbltxt using Viewer (not Mozilla). I do not want to measure the overhead 
that the chrome incurs. (4) use a simple stop watch method of measuring the 
results and don't necessarily rely on the throbber and/or cursor to indicate 
that the document is done loading. If Viewer is more than 30% slower on 
wbtbltxt, then reopen.
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
karnaze: your requirement (2) is suspect.  What if viewer thrashes where
Netscape 4.x, IE, etc. do not?  That's a bug in the code in viewer, not in the
user's lack of RAM, or in the chrome.  How much memory does your system have? 
Why should that be normative?

Let's talk about chrome too: viewer is not the product built by mozilla.org and
participating companies.  We should certainly benchmark it, but we need to see
how Mozilla does too, and file bugs (on chrome, table, or any other implicated
code) as necessary.

/be
My system has 192 MB ram which I think is enough to handle the working set size 
of wbtbltxt in Viewer. My point is that I don't want to be penalized in this 
test if wbtbltxt's working set size exceeds ram for Viewer but not Nav4.x. 
Footprint issues should be handled separately.

I also don't want to be penalized in this bug if the chrome is comming into 
play. This is a layout bug and Viewer is a better test of layout than Mozilla. 
It would be better if mozilla.org endorsed an embedded app (like win embed), but 
I'm not sure if it does.

So, if it turns out that Viewer performs ok but Mozilla is significantly worse 
then this bug should be handed over to chrome.
I'm not sure I buy that argument, Chris.  If our table code is too
memory-intensive to keep from swapping where 4.x does, then our table code has a
problem.  Footprint-as-affects-performance is still a performance issue, and I
don't think it's reasonable to punt it to ``chrome'' (whatever that means)
because Viewer -- an app that nobody is interested in shipping -- is one case
where we don't see the behaviour.

I think we'd all be happier to know that viewer does not perform well on a
system with less RAM, yet Nav4, IE, etc. still do -- in which case we need a
probable-footprint bug spun off from this one.

/be
The argument about viewer vs. mozilla is moot.  I have 512MB of ram (most of it
free).  bug 67692 is all well and good, but it's a spinoff for a specific
possible cause raised by this bug (style resolution), and that may only be one
contributing factor.

Viewer timing (PIII/800, 512MB ram, --enable-optimize, --disable-debug):
txt: 9.2s
clr: 23.2s

If you ignore color (and perhaps the difference between color and text is
wholely style - I don't know), we're still ~1.5-1.6x slowed than ns4.7, which in
my opinion was already dog-slow in most table cases.  Other browsers load these
pages in 1 second or less.

I think there's a very serious bug here.  The color test should not be 2-3 times
slower than the black and white test.  Something must be seriously screwed up
with the way the style system handles <td bgcolor="blah"/> in order to cause a
2-3 time slowdown.

IMO there are two bugs here:
(a) The color test should be comparable to the black and white test (i.e., no
more than 1.3 times slower).
(b) Both tests are way too slow.


Speaking for the screwed-up style code on the color table: when each cell has a
different background color, we end up not being able to share the style
contexts. This makes for tens-of-thousands of stylecontexts in this case, and it
just slows down the style context sharing code in a serious way. I am pretty
confident that turning off style sharing will help this case a lot, since there
is no actual sharing anyway (!) and we are spending lots of time *trying* to
share style data. However, in the large class or real-world cases, the style
sharing code is both fast and effective in reducing memory use, so I think we
would be mistaken to remove it for this case.

We could, however, put in some (minor) smarts so that when there are more than a
certain number of style contexts in the styleset, we stop doing sharing because
we know that the cost of evaluating the sharing candidates is too high. This
would, of course, make for worse memory use in many cases where we actually do
get some real sharing...

(Pierre's new style data sharing should make this a lot better since he shares
at a much finer granularity than the current scheme - see bug 43457)
Ok, on a current Win32 build, I get extremely bizarre results.

The *color* test takes 16 seconds.
The *black and white* test takes 23 seconds.

So I see the black and white one as much slower!

Marc: One possible heuristic is to say that if we get n% of misses when trying
to share contexts, then we give up. That seems a better trigger than the
number of style contexts -- on large documents there would be many style
contexts but if the document has lots of similar constructs there would also be
a lot of matches (no?).

What do I know... ;-)
Ok, I have some interesting data to share from profiling the table color stress
test.

For the color table, we perform 20103 normal style context resolutions.  We do
this to build 1 table frame, 1 table row group frame, 100 row frames, 10000 cell
frames, and 10000 whitespace-only text nodes.

I trivially cut this in half with a patch to TableProcessChild, since we don't
have to resolve style on the text nodes and can bail early.  I have it down to
only 10000 normal style resolutions.  This was taking 30.53% of the time.

We also perform 20104 calls to ResolvePseudoStyleContext.  Essentially every
table cell has *two* style contexts, both the regular one and the resolved
pseudo for the inner frame.  That's where 10000 come from.  We also have a
pseudoelement for every text node.  That's where the other 10104 come from.
This is 24% of the time.  Why do text nodes even have style contexts?  Maybe
this is a really naive question on my part, but couldn't text nodes just get all
their data from their parent frame's style context?

So style resolution is responsible for more than half of the time on this test.

10% of the 50% spent in style resolution is from the style sharing code.  This
breaks down into 6% of the time spent doing the CRC computation, 2% spent
finding a matching context, and 2% actually doing the share.  This implies to me
that style sharing is perhaps slower than we thought, and that the CRC
computation warrants a closer look.

Reflow is 13% of the time, which takes us up to 67% or so.

We spend about 10% collecting and setting attributes.  5% of this is from the
parser.  5% is making the new mapped attribute so that bgcolor has the proper
impact.  Using a pool to allocate the attribute objects like we do in XUL
already would probably give us a good little boost here.

We spend 4% of the time probing for pseudostyles.  This probing breaks down into
20000 checks for generated content, 20000 checks for first letter content, and
10000 checks for first line content.  First letter is 2% of the time.  Generated
is 1.5%, and first line is .5%.  Are we checking for first letter/first line
styles too often?



karnaze, if you don't mind, I'd like to reopen and take this bug.  I think the
issue here is not with the table code at all anyway.  It's the plumbing that
makes large tables slow, not the table code itself.


Thanks, Dave.  Your work here might help some of the more complex/lots of cells
pages out there.
Reprofiling following my patch:

Style context sharing is even more than I thought it was.

8.15% is spent in ShareStyleData, with the same 60/20/20 breakdown I described
before.

11.92% is spent in UpdateStyleSetCache!

Woof!  I think this means the sharing code is responsible for 20/50, or about
40% of the style resolution cost.

The sharing should get much better with pierre's changes.  Right now, all 27300 
style contexts are unique, so you end up with 27300 void arrays that contain 1 
element each.

Looking for r and sr on the patch to stop the resolution of style on whitespace-
only objects in between table rows and cells.

Reopening.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Hyatt, thanks for taking this. 

It looks like your patch (attachment #3 [details] [diff] [review]) is doing something similar to what is 
done in the patch of bug 23714. I'll try to check in the patch to 23714 this 
evening.
Assignee: karnaze → hyatt
Status: REOPENED → NEW
Fantastic.  r=hyatt on 27314. :)  Let me know when you check that in, and I'll 
reprofile the stress tests with it.
Status: NEW → ASSIGNED
Summary: Incremental reflow is MUCH slower/different on large tables → Large tables are slow
Marc Attinasi tried to stop resolving style on text nodes (see bug 56117),
but comboboxes depend on the bug in the style system that text nodes match
selectors.  I don't think that patch stopped text nodes from having style
contexts, though.  (I also don't see any reason that they would need to,
at least for CSS, although if current code depends on them having style
contexts we might need to add some hacks for properties that aren't
inherited when we start using the parent's context.)
The patch for bug 23714 is in. It would also be interesting to know how much 
things improved if bug 12234 got fixed (it is the one where we are reflowing 
first without space reserved for a scroll bar, then reflowing again with space 
reserved).

It won't help much, but I have an 'optimization' that gets rid of an unnecessary 
list-crawl in the style context cache. I accounts for about 10-15% of the style 
sharing time on the color table testcase. See bug 72217 - I should be landing 
this very soon. Don't get your hopes up though; style sharing really breaks down 
when there are 20,000 contexts in the system. Ian's idea about stopping sharing 
attempts after a certain failure threshold might help, but it is the old 
space/time tradeoff.
dbaron: fyi we already have such hacks, e.g. for :table-outer or :viewport. 
See the html.css file. I'm guessing we have lots of bugs there, too, that we
simply haven't yet discovered because we haven't thought to look.
karnaze, i made a patch that had the vertical scrollbar visible all the time. 
it had no effect on jrgm's page load tests.  I could try it to see if it helps
these tests.  As the profile data indicates, though, reflow isn't the problem.


Dave - you might want to check bug 71857, which is probably a dup of this.  BTW,
that's a real-world site that already existed - a coworker of mine has it, and
complained to me about how Mozilla handles it.
QA Contact: ian → amar
Target Milestone: mozilla0.9 → mozilla1.0
Depends on: 74309
Depends on: 74319
Depends on: 74328
Depends on: 74771
Depends on: 74775
Depends on: 74830
*** Bug 71857 has been marked as a duplicate of this bug. ***
mchui@bloomington.in.us: This case isn't related to layout, but to parser. 
There are about 20 occurences of a <KLR> element, which isn't closed, and it 
seems Mozilla chokes on that. If you remove those tags, the page loads in 
reasonable time. There are other bug reports about Mozilla choking on certain 
large pages, which may have the same background.
The problem with that site seems to be caused by problems placing floaters (it
produces assertions for bad floater placement).  I'll open a new bug for that
site.
Randell:
Please CC me on that bug.
Thanks.
Opened bug 81965 for floater layout issues with the oraclestore url.
From bug 71857 (marked as a dup of this); comment by Marc Attinasi:

|This is a dup of bug 54542 - the same problem but on a smaller scale. Once the
|overwhelming impact of the style sharing degeneration is fixed, if it can be,
|then we may see some differences due to the transparent images in the cells
|(this case will likely be worse, proportionally). But at this time, the problem

|is the same: too many style contexts slowing down style sharing.

Here's the URL:


(Argh, paste isn't working in mozilla today.)
http://www.sinz.org/Michael.Sinz/Art/colors.cgi
(please don't slashdot him too much).

Note that it auto-refreshes every so often. You may want to grab a copy, or look
in bug 71857.

I just tested in on the Win32 daily build.  To render the page on an 233 MMX
took about 35 seconds.  Also there are sometimes visual anomalies as well.  IE
on the same machine takes ~2 seconds.

So, we're at 0.9.1 (more or less), and there's still little or no improvement
with these style-sharing problems.
The style system is heavily reworked by Dave Hyatt in bug 78695. According to 
his figures there, the style system impact on this table case will be almost 
gone (knock on wood). Quote from that bug:

"(b) The 100x100 color table stress test has dropped from 18 seconds on the 
trunk to 4.5 seconds on my branch."
Depends on: 78695
On my machine using my style branch, the colors.cgi table loaded in 1.3 seconds.

Yeah, me too!. Oops, but wait for the 'Refresh: 60' header to load the page 
again. Then the page load takes me ~20 seconds (500MHz/win2k/128MB). I broke in 
the debugger and something odd is happening in HTTP and/or Cache (but it's not
style resolution). I'm reopening the other bug on that point.
Depends on: 83624
Is bug 74888 a dup of this (I see no difference between them) or maybe this one
should depend on 74888?
Depends on: 84194
Depends on: 90503
Depends on: 90725
Depends on: 90723
Depends on: 90870
Depends on: 90871
Depends on: 89567
Depends on: 91674
doing a query for all NEW bugs in bugzilla with NC 4.* loads the page
continously, it's all rendered in a matter of a minutes time, and once page is
loaded it's ready to scroll and click links in.

Same query with Moz caused me a 15 minute freeze AFTER the content is
transmitted. I can scroll during load, actually almost all the way to the bottom
of content. The freeze starts immediately after content is onboard. Duing the
freeze moz uses 95% CPU and at the time i didn't care to wait for it anymore and
killed it, it was allocating 153MB resident RAM.

P3/500, 512MB RAM, RH7.1, CVS from Aug. 24th.
*** Bug 99901 has been marked as a duplicate of this bug. ***
Depends on: 74888
Blocks: 104166
Has this regressed badly? The color case used to take ~5 seconds for me. Now it 
takes 17-18 seconds, while the browser seems hung.


are you trying today's build?
if so, we found a bad regression in page loading...  hyatt and dbaron has a fix
ready to go in as soon as the tree opens.
I just rebuilt and the problem is still there. Really there are two problem. 
First there is no incremental update so the page is white (and the browser 
hung?) for th 17 seconds. Second there is the layout time. I looked at the main 
thread in a profiler but saw nothing out of the ordinary, so either it's blocked 
by some other thread or some other thread is running wild. I'm loading from a 
local file if that helps people reproduce what I see.
Target Milestone: mozilla1.0 → mozilla1.0.1
No longer depends on: 91674
No longer depends on: 74771
Between 10/17 and 10/27 there does appear to have been a regression in how it
displays while loading - it now does not display until the page is fully
loaded/rendered; before it did (though after a significant delay).

I didn't closely time it, but overall speed seemed similar.  It appears to be
much slower because of no incremental reflow/display.

Win2000, 10/17 and 10/27 dailies.
Click on http://www.quickshop.be/web/product/oem/catalogue.htm - flashes a lot
and is terribly slow.....
*** Bug 110251 has been marked as a duplicate of this bug. ***
Bug 110251 has some nice testcases and timings against IE and Opera on Win2k.

We really should make another attempt to address large tables before 1.0.
Keywords: mozilla1.0
Note that almost 30% is direct hits in FindFrameWithContent, with another 20%
in descendants.  Total 2900/5800.  Something is WAY wrong here.
Depends on: 63890, 77114
Total CPU for GetPrimaryFrameFor is ~58%.

This is yet another reason we need to speed up GetPrimaryFrameFor and it's
children.  According to the comments in the code, the only reason we're doing
this is for history (probably form history).  Perhaps we can turn the problem on
it's head somehow, since most content isn't forms?

See bug 63890 and especially bug 77114
I'm posting a recent jprof of the main URL for this bug (wbtblclr.html).  It
also shows a hotspot, but it's not the same; it's in the CSS rules code at
nsCSSFrameConstructor::ResolveStyleContext() (42% of total); it's descendant
nsRuleNode::Transition() has 34% of the total time in direct hits.

Note also that GetPrimaryFrameFor() doesn't even show up; so we have (surprise)
multiple problems.

I'm going to jprof the text-only table as well.

rjesup: Don't jump to the conclusion that we need to speed up GPFF. What we need
to do is fix PresShell::ContentAppended. See bug 109482. Re-run this test after
#if 0'ing out the code that tries to restore frame state for _every_ frigging
frame that gets appended.
Depends on: 109482
waterson meant bug 109428.

/be
Bug 109482: Box Model tab should have option to show all numbers

I don't think you meant that one. :-)

The comments in 109428 imply this isn't a big win for normal pageload, and
that's right (GPFF takes about 0.5% of dbaron's pageload jprof) - but on a
number of large pages (like the c't page and some others I've jprofed) it's a
MASSIVE win.

77114 (or at least some of the commentary there) seems to cover what you said;
we constantly call GPFF from ContentAppended because of history/form reasons.

I'm not really saying we need to optimize exactly this routine; mostly just
pointing out where the time went.
For the text-only version, it's harder to find glaring issues.  I would note
that 14% or so is spent in StyleSetImpl::FileRules(), 5% in
nsFontCache::GetMetricsFor;
8% in SinkContext::FlushText, etc.
I'll be re-running the tests tomorrow with the change waterson suggested.  I
agree that it's the real major culprit for most cases of GPFF showing up in
jprofs on large pages.
This page takes Mozilla >60 seconds to complete, while
IE renders it in 4 seconds.

http://tite.cs.tut.fi/~ruffe/urlit/

That "urlit" URL takes about 3-4 seconds to render on Opera 5.05TP1 for Linux.
someone care to explain what dom inspector bug 109482 has to do with table perf?
someone typoed; it's bug 109428
Depends on: 109428
No longer depends on: 109482
Depends on: 85755
Is somebody working on this? It would be great to get this to 1.0.0.
IMHO this is the worst thing in Mozilla at the moment.
Keywords: nsbeta1
Time for the mail URL (colored table from mozilla.org), 2/11/2002 pull/build,
-O2, Linux RH 7.1, dual PIII/450, lots of memory, going back to the page via
Forward:

colored table:     16 seconds
text table:         7 seconds

These aren't great times given a fast system.  What happened to hyatt's fix in
comment http://bugzilla.mozilla.org/show_bug.cgi?id=54542#c96 ?

>The style system is heavily reworked by Dave Hyatt in bug 78695. According to 
>his figures there, the style system impact on this table case will be almost 
>gone (knock on wood). Quote from that bug:
>
>"(b) The 100x100 color table stress test has dropped from 18 seconds on the 
>trunk to 4.5 seconds on my branch."

Also, dbaron's patch for GPFF being called from ContentAppended doesn't really
help here; the color table is stuck in style resolution, and the text version in
a mixture of style, text width, etc.
Keywords: topperf
I just did a jprof profile of loading
http://www.mozilla.org/newlayout/testcases/stress/wbtblclr.html .  About 50% of
the time is in nsRuleNode::Transition -- I suspect because of the hashtable
removal that hyatt did a while back, which was an overall performance gain, but
hurts the case where there are tons of elements with style attributes or mapped
attributes that otherwise match the same selectors (at least that's my guess as
to what's going on).
Attachment #17533 - Attachment is obsolete: true
->html tables (karnaze?)
Component: Layout → HTMLTables
->style system, see comment #126.
Component: HTMLTables → Style System
->component
Assignee: hyatt → dbaron
Status: ASSIGNED → NEW
QA Contact: amar → ian
Keywords: mozilla1.0+
Keywords: mozilla1.0
I'm going to fix the nsRuleNode::Transition issue here using bug 129187, since I
have another, much less cluttered, bug on it.
Bug 129187 is now fixed, and things are a bit faster.  Back to HTMLTables
component.  Bug 129187 actually has an even slower testcase than the one for
this bug.
Assignee: dbaron → karnaze
Component: Style System → HTMLTables
QA Contact: ian → amar
nsbeta1-. Engineers are overloaded with higher priority bugs.
Keywords: nsbeta1 → nsbeta1-
Keywords: mozilla1.0+ → mozilla1.0-
Rendering large table is very slow on mozilla solaris version.
I did some profile using quantify on solaris to access the testcase.
I collect data from nsDOCShell::LoadURI() to nsFileChannel::OnStopRequest().
From the profile result, we can see that GetStyleData() cost much time.
Severity: critical → major
Status: NEW → ASSIGNED
Target Milestone: mozilla1.0.1 → Future
Depends on: 145939
Keywords: mozilla1.0-, perf → mozilla1.1
Depends on: 153539
Keywords: nsbeta1- → nsbeta1
Do we have a chance that this will make it by 1.3?
Markus: Pls provide a comment/propositon when renominating for nsbeta1. thanks!
Running the testcase (attached) takes 27secs on trunk build 2002091014 and 
8secs on MSIE6 / 5secs on Opera6 - all tested locally. (using a 1.1ghz,512ram 
win-xp pro workstation).

As dbaron pointed out we are doing a bit better now but are still far away. 
Great investigation has been done in the past and we know (dependency bugs) 
what to do to fix this.

more testcases are here:

[text]
http://www.heise.de/ix/browser/tables/index.php?
what=text&my_trlimit=1000&my_tdlimit=3

[text & graphics]
http://www.heise.de/ix/browser/tables/index.php?
what=textgraf&my_trlimit=50&my_tdlimit=3

[graphics]
http://www.heise.de/ix/browser/tables/index.php?
what=grafik&my_trlimit=100&my_tdlimit=5

All testcases have parameters trlimit and tdlimit for further testing.

Darn X crashed.  Starting again...

I did a new jprof.  25s wall-clock, about 1700 hits.  Warning, this is from an
optimized DEBUG build.  I tried to avoid routines that seemed to be mostly
DEBUG-only checks or adjusted the time below (such as GetBidiEnabled).

% is % of total hits unless otherwise specified.

6% in nsHTMLReflowState::nsHTMLReflowState (2 variants)
~1% in GetBidiEnabled, from nsTextFrame:Reflow
3% in nsBlockReflowState::nsBlockReflowState, most of that in CalcLineHeight
close to 1% in nsBlockFrame::DrainOverflowLines
10% in nsStyleContext::GetStyleData, mostly for visibility and color data, 80%
of which ends up in WalkRuleTree
5% in nsBlockFrame::PlaceLine, mostly in VerticalAlignLine, which is mostly
SetFontFromStyle, which is mostly nsFontCache::GetMetricsFor
4% in nsTextFrame::TextStyle::TextStyle, mostly SetFontFromStyle and GetStyleData
2% in nsTextFrame::MeasureText
0.6% in TrimTrailingWhitespace

On parsing side, we have:
4% in Tokenize
4% in nsGenericHTMLContainerElement::AppendChildTo
2% in nsCellMap::AppendCell
8% in nsCSSFrameConstructor::ResolveStyleContext, mostly
StyleSetImpl::ResolveStyleFor
9% in StyleSetImpl::FileRules (partly from ResolveStyleFor)
20% in nsCSSFrameConstructor::ConstructTableCellFrame, most of which ends up in
the style system, plus about 1.5% in ChildIterator::Init
9% in SinkContext::OpenContainer


This sounds like a job for ... BERND!
Blocks: majorbugs
Blocks: 152385
thanks for the honour, but I am not able to fix this any time soon. If I
continue to gain understanding of mozilla at the current speed: eta 2005.
Target milestone: mozilla2.5 ? ;-)
nsbeta1-, Karnaze is overloaded with other issues.
Keywords: nsbeta1 → nsbeta1-
Keywords: mozilla1.1, nsbeta1- → mozilla1.3, nsbeta1
Blocks: 109885
-> Jkeiser. nsbeta1-.
Keywords: nsbeta1 → nsbeta1-
mass reassign to default owner
Assignee: karnaze → table
Status: ASSIGNED → NEW
QA Contact: amar → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
No longer depends on: 74888
*** Bug 74888 has been marked as a duplicate of this bug. ***
Blocks: 203448
Depends on: 148338
Keywords: nsbeta1- → nsbeta1
Target Milestone: Future → ---
adt=nsbeta1-
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → Future
*** Bug 216347 has been marked as a duplicate of this bug. ***
Depends on: 226243
Blocks: 234240
Apologies for the bugspam, but this bug (and its dependencies) have seen
precious little action in the last few months.  My company just nixed the idea
of using Firefox after noticing that some of our intranet pages (which contain
tables of up to about 1000 rows) took up to a minute to load, compared with less
than 10 seconds on IE 6.  Most of these dependencies are very low-level stuff,
which I understand must be tough to program, but there must be someone out there
to look at this stuff!
Depends on: 236476
Depends on: 240561
I have added a new testcase for this bug. Execution speeds on a 1GHz P3 Win2k
machine:
Mozilla 1.7RC2: 82sec!!!
IE 6.0: 3sec
Firefox 0.8: 33sec
Sorry for the spam, but I have an observation, we have big html log4j log files
(2MB, a few thousands rows) and Firefox 0.8 was terribly slow at rendering them,
but as I tested the same files with Firefox 0.9 I'm shocked to see Firefox now
renders tables faster than IE. Now Firefox renders a 2MB html table (about 5000
- 6000 rows, 5 columns) in about 6 seconds, and IE renders same file in 7-8
seconds (P4 - 2.8Ghz, 1 GB RAM) and if you resize the window after loading page
Firefox is much more responsive than IE.

Can anyone confirm this? I dont know what changed but Firefox seems to be much
more faster on tables.
Keywords: mozilla1.3
is it possible to setup a serious test case with maybe js ?
so eg you can do a microtime at start and end, will that reflect the actual
rendering time ?
Found that this bug shows itself using PHPMYADMIN (lots of tables displaying
data from SQL server).  Any hints as when this would be fixed?
see comment 140 or comment 141
*** Bug 251167 has been marked as a duplicate of this bug. ***
(In reply to comment #150)
> Created an attachment (id=149508)
> Testcase with drop-down menus
> 
> I have added a new testcase for this bug. Execution speeds on a 1GHz P3 Win2k
> machine:
> Mozilla 1.7RC2: 82sec!!!
> IE 6.0: 3sec
> Firefox 0.8: 33sec
> 

I've run the new testcase on a 1Ghz P3 Win2K (385 mb mem) and I've found the
following excecution speeds:
Mozilla 1.7.2: 8 sec
IE 6.0: 3 sec
Firefox 9.2: 7 sec

I have no idear how to explain the differences on seemingly indentical machines.
*** Bug 252421 has been marked as a duplicate of this bug. ***
Seems bug 277984 is related / dupe?
No longer blocks: majorbugs
*** Bug 309355 has been marked as a duplicate of this bug. ***
*** Bug 242160 has been marked as a duplicate of this bug. ***
*** Bug 328858 has been marked as a duplicate of this bug. ***
Depends on: 277984
*** Bug 352187 has been marked as a duplicate of this bug. ***
Not a lot of activity on this bug, it seems. 
I came across this bug in FF Version 2.0.1. when loading a page with a large table (around 400 rows). 
When loading the same table with FF 1.5 I don't have a problem. 
I see the idea that the page is supposed to load in the background, while the user can look at the first rows. 
My problem is that I do some javascript formatting (not displaying some rows,...) after the page is loaded. 
Is there a HTML or javascript directive to load the whole page at one go?
(like it is done in FF 1.5)
Or is there a javascript function that can be called anytime, a new chunk of data is loaded? 
(In reply to comment #158)
> Seems bug 277984 is related / dupe?

Is it possible that Bug 352367 is yet another dupe?

Hello all,

Can someone *_clarify_* what this bug is about?
Is this bug about slow at rendering large tables?
Is this bug about slow at scrolling large tables?
Is this bug about incorrect rendering large tables?
There should be only one bug per report.
Please clarify/sort this out and resummmarize accordingly so that bugzilla QA work (confirming, searching for duplicates, resolving, etc) can be better for everyone involved.

Thank you, Gérard
Gerard Talbot, the bug is about SLOW SCROLLING OF LARGE TABLES primarily. 

example: http://www.zybez.net/statsgrabber,new.php
No, it's not.  Based on comment 0, it's about incremental reflow.  It's not about painting or scrolling.
Bug 421601 is about scrolling large tables.
Bug 352367 is rendering large tables with many form elements.

This bug is for slow incremental rendering of all large tables. If you watch the progress bar loading the test case in ltable.htm, you will see it slow down as the table loads, indicating that load speed slows as the number of elements increases.  In Konquerer (for example) the progress is linear.  On my system, Konquerer loads the page in 14 seconds, vs. 88 for Firefox.
Assignee: layout.tables → nobody
QA Contact: madhur → layout.tables
The testcases load quite fast for me. Shouldn't this be marked as fixed or wfm?
I think this should be marked as fixed, as the testcases are now fast.
Resolving WORKSFORME.
(that's what we use when a bug's testcases start working correctly, but we don't know precisely what patch fixed it)
Status: NEW → RESOLVED
Closed: 23 years ago → 13 years ago
Resolution: --- → WORKSFORME
Original reporter here.

I tested the "large table" testcase from Marcus (ltable.htm), and then doubled it and doubled it again to check for O(n^2) issues.

Performance decay was linear to a 1-one-thousand-2-one-thousand measurement.  Since it appears linear now, I concur WORKSFORME.  

Marco: please note that an *old* testcase being fast isn't always enough to know the problem is gone.  You need to understand more about the test and often write new testcases.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: