151461 - Table DOM construction/manipulation performance (benchmark)

Status: NEW

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

Description

[Markus Hübner]

Rendering this page using a 1.1ghz,512ram,win-xp
2002061204 trunk build: 8110 ms
MSIE6: 5969 ms

Comment 1

[Gilles Durys]

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

Comment 2

[Gilles Durys]

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

Comment 3

[Manfred Schneiderbauer]

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.)

Comment 4

[Manfred Schneiderbauer]

More test results:

AND 800 / Win2K:

Moz 1.0 20020530 -> 12700
IE 6.1 -> 4600

Comment 5

[Boris Zbarsky [:bzbarsky]]

Just throwing out numbers is not useful without a profile...  I will try to
generate one once I have a build env again.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: profile

Nothing jumps out at me here....

Comment 7

[Markus Hübner]

current results:
trunk build 2002071108 on win-xp,1.1ghz,512ram
9284ms vs. 7190ms (msie6).

Comment 8

[Markus Hübner]

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

Comment 9

[Markus Hübner]

This testcase is the same as in bug 168157 - there is also a jprof profile as
well as some investigation going on.

Comment 10

[Markus Hübner]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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.

Comment 12

[karnaze (gone)]

mass reassign to default owner

Comment 13

[Guilherme Lima]

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.

Comment 14

[Boris Zbarsky [:bzbarsky]]

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).

Comment 15

[Boris Zbarsky [:bzbarsky]]

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).

Comment 16

[Johnny Stenback (:jst)]

Smaug, do we still have HTML5 innerHTML optimizations waiting to go in that might help with document.write() here as well?

Comment 17

[Olli Pettay [:smaug][[e-mail]]]

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)

Comment 18

[Boris Zbarsky [:bzbarsky]]

> 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.