922554 - removeAttribute("id") much slower than in Chrome and Safari

Status: NEW

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

Description

[Jan de Mooij [:jandem]]

Attachment: Testcase

I'm attaching a testcase that does just:

    for (var i = 0; i < 18000; i++) {
	body.id = "foo";
	body.removeAttribute("id");
    }

Safari 6.0.5:  6 ms 
Chrome 31:     8 ms
Nightly 27:   80 ms

Why is Webkit > 10x faster? Can we do something similar?

jQuery does setAttribute/removeAttribute, see bug 922053 comment 2.

Comment 1

[Olli Pettay [:smaug][[e-mail]](vacation until July 14)]

(sounds like rather silly test.)

nsIMutationObserver notifications take a lot of time, up to 40%, and the time is mostly spent
somewhere in layout and style. RestyleManager::AttributeWillChange and and RestyleManager::AttributeChanged.

Could we cache the return value of HasAttributeDependentStyle

Comment 2

[Boris Zbarsky [:bzbarsky]]

Jan, WebKit mostly gets this fast at the expense of some CSS bugs and some extra time spent doing CSS processing later, last I checked....

We can certainly make the microbenchmark case of AttributeWillChange/AttributeChanged faster, though: we should have a single object that handles it, instead of virtual function calls across 5-6 objects.  So basically, have the various rule processors tell some other object about all their attribute dependencies and have DOM query that object.

Comment 3

[Boris Zbarsky [:bzbarsky]]

When I try the testcase from comment 0 on nightly, Safari Tech Preview, and Chrome dev, I get:

Safari: ~10ms
Chrome: ~10ms
Nightly: ~17ms

So we're not quite at parity yet, but we're a lot closer...

Comment 4

[Boris Zbarsky [:bzbarsky]]

https://perfht.ml/2GXFJIZ is a profile of the testcase with the iteration count bumped.

Lots of thrashing of hashtables (the atom table and that id table most obviously).  Lots of atom refcounting.  Not much else jumping out at me....