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

Sam Weinig sam.weinig at gmail.com
Wed Oct 1 10:29:29 PDT 2008

On Wed, Oct 1, 2008 at 1:46 AM, Geoffrey Garen <ggaren at apple.com> wrote:

> > In the Chrome tree, every object inheriting from RefCounted incurs
> > an extra pointer in size, but this is clearly more than necessary
> > since many RefCounted objects do not have bindings.
> If we believe that JS wrappers are relatively uncommon, we can store
> them in a Node's "rare data" structure, and bloat only those uncommon
> nodes that have JS wrappers.
> If we believe that JS wrappers are relatively common, we can store
> them directly in a Node, since putting them in a hashtable is net more
> memory use.

This does not have to be an all or nothing strategy.  One idea we have
discussed was to use different strategies for different classes based on how
likely we believe they are to need a binding.  For instance, if (since?)
HTMLElement is more likely than Text nodes to need bindings, we could store
a pointer for HTMLElements and fallback to the HashMap or RareData for Text.

Regardless, I think the real blocker here is hard data.  We would love to
see what the V8 team has found and how they tested those findings.

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

More information about the webkit-dev mailing list