Open Bug 151461 Opened 20 years ago Updated 11 years ago

Table DOM construction/manipulation performance (benchmark)

Categories

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

x86
Windows XP
defect

Tracking

()

Future

People

(Reporter: markushuebner, Unassigned)

References

(Blocks 1 open bug, )

Details

(Keywords: perf)

Attachments

(1 file)

Rendering this page using a 1.1ghz,512ram,win-xp
2002061204 trunk build: 8110 ms
MSIE6: 5969 ms
Keywords: perf
*** Bug 151459 has been marked as a duplicate of this bug. ***
*** Bug 151460 has been marked as a duplicate of this bug. ***
Win2K @ 1GHz:
IE5.5 -> 9593ms
Moz 1.0 20020530 -> 16600ms

SuSE Linux 8.0 @ 1GHz:
Moz 1.0 20020529 -> between 21000ms and 238000

(however, i haven't yet optimized the script for speed anyway.)
More test results:

AND 800 / Win2K:

Moz 1.0 20020530 -> 12700
IE 6.1 -> 4600
Just throwing out numbers is not useful without a profile...  I will try to
generate one once I have a build env again.
Whiteboard: profile needed to go anywhere
Priority: -- → P3
Attached file profile
Nothing jumps out at me here....
current results:
trunk build 2002071108 on win-xp,1.1ghz,512ram
9284ms vs. 7190ms (msie6).
Whiteboard: profile needed to go anywhere
Target Milestone: --- → Future
Using trunk build 2002122508 Mozilla isn't responding while rendering the 
table (the text with blue background up to where the table starts rendering is 
displayed though).
Also the time went up for rendering: 12618ms
This testcase is the same as in bug 168157 - there is also a jprof profile as
well as some investigation going on.
In regard of this bz did some investigation in bug 23187
Up to now seems document.write isn't the bottleneck - maybe dbradley's profile 
in bug 168157 will reveal more.
Just a quick note.  My comments in bug 23187 have nothing to do with this bug,
and comment 10 has nothing to do with anything.
mass reassign to default owner
Assignee: karnaze → table
QA Contact: amar → madhur
Target Milestone: Future → ---
Target Milestone: --- → Future
Assignee: layout.tables → nobody
QA Contact: madhur → layout.tables
On Windows XP, P4 3.0 ghz (old machine)
Firefox 3.6.3
3359ms

Chrome 4.1.249.1064
1596ms

IE 8
2531ms

I'm sorry not using trunk. Just showing after lot of development firefox still lags behind on this test. Someone could test trunk? And someone with enough knowledge could tell what bugs should block this one? Sorry if I'm spamming.
Fwiw, over here (Mac, medium-age laptop) I see 1500ms or so for Fx 3.6 and 1200ms for trunk.

And of course there's the side issue of the test not really measuring something useful (e.g. doesn't measure the time needed to lay out the things it's adding to the DOM).
I did a profile of the testcase as-is in all its brokenness, and about 50% of the time is under the document.write calls in the html5 parser and various content bits (attr setting, etc).
Blocks: domperf
Smaug, do we still have HTML5 innerHTML optimizations waiting to go in that might help with document.write() here as well?
Summary: Table rendering performance (benchmark) → Table DOM construction/manipulation performance (benchmark)
This is about document.write, not about innerHTML, right?
(There sure are fixes coming to innerHTML, but I haven't even looked at document.write)
> This is about document.write, not about innerHTML, right?

Yes.  Though note that the bulk of the time is under Parse() and the resulting DOM construction, so code that's shared with innerHTML, really.
You need to log in before you can comment on or make changes to this bug.