922016 - Peacekeeper domDynamicCreationCreateElement test slower than in Chrome and Safari

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Jan de Mooij [:jandem]]

Attachment: Testcase

Attaching a minimal, standalone version of http://www.peacekeeper.therichins.net/test16.html

Safari 6.0.5: 1189 ms
Chrome 31:    1512 ms
Nightly 27:   2017 ms

We seem to spend a lot of time setting innerHTML. When I remove these assignments:

Safari 6.0.5:  645 ms (544 ms faster)
Chrome 31:     723 ms (789 ms faster)
Nightly 27:   1079 ms (938 ms faster)

So it looks like setting innerHTML is slower than in Safari and Chrome, but it's not the only problem.

If I also comment out the className assignments:

Safari 6.0.5:  383 ms (262 ms faster)
Chrome 31:     469 ms (254 ms faster)
Nightly 27:    853 ms (226 ms faster)

Not much of a difference here.

If I also comment out |clear.style.clear = "both";| I get:

Safari 6.0.5:  308 ms (75 ms faster)
Chrome 31:     377 ms (92 ms faster)
Nightly 27:    491 ms (362 ms faster)

These numbers show that setting innerHTML and clear.style.clear make us a lot slower, especially compared to Safari.

With all that commented out, what's left is various document.createElement("div") and appendChild calls.

Comment 1

[Boris Zbarsky [:bzbarsky]]

So what I see here is that we spend time as follows:

1) 35% of our time under SetInnerHTML.  A bunch of this is malloc/free and other parser state management.  Now note that the strings passed to the innerHTML setter in this testcase are "10451", "3DMark06", and "AMD Athlon(tm) 7750 Dual-Core Processor 2702 MHz ATI Radeon HD 4850".  I seem to recall seeing bugs before about WebKit being faster than us on innerHTML setter cases that don't involve markup, but can't find them offhand...

2) 22% createElement (half of this is creating the JS object reflection, note!).

3) 9% appendChild

4) 12% setting className (typical SetAttr profile here).

5) 4-5% JS engine proxy overhead to get to set_clear.

6) 10% under set_clear.  This seems to have the usual expand/compress bits on the CSS
   data block, Get/SetCSSDeclaration, etc.

We probably need specific bugs blocking this one on speeding up the innerHTML and style pieces.  :(  And I thought we already had bugs on the JS engine for the set_clear bit being slow in proxy code...

Comment 2

[Henri Sivonen (:hsivonen)]

It's unclear to me what exactly I was needinfoed for. If to comment about the possibility of bypassing the HTML  parser in some cases, I guess we could take a shortcut in some cases (depends on the element!) if we loop over the input string to verify that it has none of these characters:
 <
 &
 \r
 \0

Comment 3

[Boris Zbarsky [:bzbarsky]]

It was partly for that and partly for the malloc/free bits under parser and whether there's a way to make that happen less.

Comment 4

[Boris Zbarsky [:bzbarsky]]

I filed bug 922016 on investigating a shortcut here.

Comment 5

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

With local m-i build I get 1450ms with the testcase, and Chrome32 is ~1750ms

Comment 6

[Boris Zbarsky [:bzbarsky]]

Sounds like we might be able to call this fixed...

Comment 7

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

Well, might be worth to test on OSX too and compare to Safari.

Comment 8

[Boris Zbarsky [:bzbarsky]]

On my Mac:

Current inbound: 1277 ms (was about 1900 before bug 922681 was fixed).
Chrome dev: 1674 ms.
Safari 6.1: 2343 ms.
WebKit nightly: 2386 ms.

Comment 9

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

Ok, fixed then :)