[webkit-dev] JS binding wapper pointers: inline vs. separate hash table

Peter Kasting pkasting at chromium.org
Wed Oct 1 16:48:49 PDT 2008

On Wed, Oct 1, 2008 at 4:40 PM, Maciej Stachowiak <mjs at apple.com> wrote:

> Do we have any measurements of the performance benefit?

Copying verbatim Feng's post on this from the other thread into this one:


I did some performance measurement a few weeks ago. I made a version
of Chrome without Peerable (except SVG), it allows me to run many
I wrote a macro benchmark to exercise DOM -> JS wrapping code as much
as possible:
 // collect all nodes in the page
 for (var j = 0; j < num_nodes; j++) {
   var a = nodes[j];
   for (var i = 0; i < 10; i++) {
     a.parentNode; a.childNodes; a.firstChild; a.lastChild;
     a.previousSibling; a.nextSibling; a.attributes; a.ownerDocument;

These Node properties all return a DOM node, and it loops several
times to minimize the overhead of other JS constructs.
I reused Dromaeo framework to run the test. The test page has ~4600
nodes. Using Dromaeo framework to run the test along, I observed that
with Peerable cache, it is about 7~8% faster. When the test with other
Dromaeo tests, I observed that Peerable was 25% faster, but other
tests either faster or slower, so I cannot tell if that's because of
real impact of caching or some other effects. One thing for sure is
that when running whole Dromaeo tests, the memory usage went to to
430+MB. That's may have an effect.

I think the performance difference can even be measured outside of
browser, it really measures how much performance improvement of a
cache on top of a hashmap vs. the memory overhead and maintenance


Again, I think the current memory cost is much higher than it needs to be,
so this tradeoff can become more favorable.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081001/192978f9/attachment.html 

More information about the webkit-dev mailing list