684305 - Make <DOM Thing>.className fast

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[Brian Hackett [Laid off!]]

As identified in bug 683631, jQuery can access the .className of DOM objects a lot (this is biased by the selectors which Dromaeo uses when testing jQuery, but this still seems a reasonable position).

<div id="fubar"></div>
<script>

A) var div = document.getElementById("fubar");
B) var div = {className:"hello!"};

var start = new Date;
for (var i = 0; i < 5000000; i++)
  div.className;
alert(new Date - start);

</script>

Times:    A)   B)

Fx6:      366  42
TI:       458  20
Safari:   115
Chrome:   220
Opera:    1400

I'd like to get A) to as close to 20ms as reasonable.  This means being able to do this access efficiently while staying in jitcode.   Mostly though this is helpful for me to look into while understanding how our DOM works and what larger things need to change for this to be possible.

Comment 1

[Brian Hackett [Laid off!]]

With the getter PIC stuff on the JM branch, column A) for TI is 210.

I made a mistake with the original testcase, though.  Getting the .className of an element with an empty name takes a fast path and avoids XPCOM string marshaling overhead.  Revised numbers with <div id="fubar" class="what"></div>:

Fx6:     610
TI:      415
Safari:  207
Chrome:  235
Opera:   2005

Comment 2

[Boris Zbarsky [:bzbarsky]]

Sounds pretty good.

How do the numbers look on fx6 if you disable JM and jitprofiling (forcing the loop to run in TM), on your hardware?

Comment 3

[Brian Hackett [Laid off!]]

With the original testcase, I get 240.  With the comment 1 modification, I get 510.

Comment 4

[Boris Zbarsky [:bzbarsky]]

OK, great.  Sounds like I should do some profiling on the testcase from the xpconnect/xpcom side once bug 557358 lands!

Comment 5

[Boris Zbarsky [:bzbarsky]]

OK.  So the profile now generally looks like this:

17% mjit code
30.6% self time in nsIDOMHTMLElement_GetClassName.  I believe that that unwrapping got
      inlined into that method.
15% converting the XPCOM string return value to a jsval (XPCStringConvert::ReadableToJSval
    and self time in xpc_qsStringToJsval).
5% is the className getter itself (call overhead, mostly)
24% under GetAttr (over half of this is the SetLength on the return-value string).

So it's the usual story: our string situation sucks and unwrapping is slow.  :(

Comment 6

[Boris Zbarsky [:bzbarsky]]

Attachment: Testcase modified per comment 1

On this testcase, I see the following on my hardware:

Fx6:     400
Safari:  116
Chrome:  100
Opera:   1544
Fx27:    182

A current profile has 45% under Element::GetAttr, 18% under NonVoidStringToJsval, 12% under nsAString_internal::Finalize, 15% self time in get_className, 10% jitcode.

Comment 7

[Boris Zbarsky [:bzbarsky]]

With the changes in bug 976272 (just the DOMString bit, not the [Pure] bit) we're at 95 on that testcase.  jitcode is now 25% of the time, the C++ getter is about 30%, and the rest is binding code.

Note that this is with a cache hit on the one-slot cache, though...  If I change the testcase to get the classname of two nodes in alternation, we go back to being 2x slower than Chrome (though Chrome ends up about 3x slower, not 2x slower; we just end up 6x slower).

Comment 8

[Mayank Bansal]

Chrome : 44
Nightly: 5
I think we are good here.