Intent to Implement: Fast(er) DOM Accessors

[Daniel Vogelheim]

Contacts

pete...@google.com, voge...@chromium.org

Spec

This work should be unobservable by web developers, except for performance. It follows the DOM spec (Interface Node), as does the current implementation.

Summary

Re-implement select DOM accessors for improved speed.

Motivation(s)

At present, DOM access from JavaScript in Chromium is not always as fast as it could be. In some benchmarks that heavily exercise DOM access we trail other browser on the same hardware.

We suspect the culprit being the Blink/V8 bindings, which are highly optimized for common access patterns, but may not do so well in other, less-common ones. In particular, the combined time of V8 jumping out of the VM plus the bindings adds a small constant overhead to any call, which is very noticeable it the useful net work done within that call is very small. An example for this are very simple accessors like firstChild, where the net work done is effectively a check on the node's flag field and access of a member variable.

This work uses a new technique, V8-assembled accessors, which allows us to re-implement several simple DOM accessors (firstChild, nextChild, previousSibling, nextSibling) so that V8 can compile the accessor code directly within V8, at least in the common case. This way, an access to these accessors from JavaScript can be executed entirely within the V8 runtime and does not require V8 to jump back into the C++ runtime and into the Blink bindings.

Interoperability and Compatibility Risk

None. This should be invisible to web developers (except for performance).

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, Chrome OS, Android, and Android WebView)?

Yes.

OWP launch tracking bug

crbug.com/648534

Link to entry on the feature dashboard

n/a [This isn't a web facing change.]

Requesting approval to ship?

No: We'd like to implement the accessors behind a flag first, to gather more data about the real-world performance impact.

[Kentaro Hara]

Are you planning to implement both Fast DOM Accessors and the mechanism to cache DOM attribute getters (which you're proposing for window.document)?

I'm wondering if the latter would be enough to speed up common DOM attribute getters.

--

Kentaro Hara, Tokyo, Japan

[Daniel Vogelheim]

On Tue, Sep 20, 2016 at 11:27 AM, Kentaro Hara <har...@chromium.org> wrote:

Are you planning to implement both Fast DOM Accessors and the mechanism to cache DOM attribute getters (which you're proposing for window.document)?

I'm wondering if the latter would be enough to speed up common DOM attribute getters.

Yes, I would like to implement both. The caching one is an intent-to-ship, since we're quite sure this is immediately beneficial. This one is an intent-to-implement, since we'd like to get a better understanding of the real-world performance impact before a full release.

In their current state, these two mechanisms aren't really interchangeable: One (caching) requires more memory per object; and requires an update mechanism for each property. For node traversal accessors, it would require some changes blink's DOM implementation to support the update. The other one ('fast accessors', this one) requires no per-object memory, leaves blink's DOM implementation largely alone, and merely provides a different way to access the same data.

We could try to extend the 'caching' mechanism to handle both cases, but I think that would 1, hold this up by quite a bit and 2, has some uncertainty around memory use, since each Node wrapper would gain four additional JavaScript members.

[Kentaro Hara]

Yeah, extending the attribute caching to handle both cases sounds like a reasonable approach.

My concern about the fast DOM accessor is that it will introduce extra complexity to the binding layer. I'm not really happy about having two mechanisms (=fast DOM accessor and attribute caching) that do similar things.

Maybe can we mitigate the concern just by making the V8 API of the fast DOM accessor closer to the V8 API of the attribute caching? In the attribute caching, Blink registers a callback that returns a private property so that V8 can access the private property without leaving JIT. We can do a similar thing for the fast DOM accessor: Blink registers a callback that returns an offset of a given DOM attribute so that V8 can access the attribute without leaving JIT. Then we can realize the two mechanisms using the same style API.

What do you think?