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

[Maciej Stachowiak]

One of the changes in Chrome's version of WebKit is that, instead of  
storing pointers to the JS binding object for a core object in a  
HashMap, it stores them directly in the core object. Although this  
change is not currently in the webkit.org tree, and is in the Chrome  
tree for the V8 bindings only, it's really independent of the choice  
of JS engine.

I gather some members of the Chrome team are gathering data on the  
memory cost and speed benefit, and will post that data soon. In the  
meantime, I decided to do a quick and dirty hack to do a rough estimate.

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. I assume this would be  
narrowed if the change were to go into webkit.org WebKit. But rather  
than find every class that may have a binding, I just counted objects  
inheriting from Node, StyleBase or NamedAttrMap on popular sites, and  
multiplied by 4. This does not count some bindable objects and does  
not account for allocator overhead, so these are lowball estimates. (I  
am also assuming that most bindable objects on these pages do not have  
a live JS binding).

GMail (load to inbox): ~135k
Slashdot main page: ~70k
Google docs start page, plus Ian Hickson's "element nesting matrix"  
spreadsheet: ~155k
daringfireball: ~16k
facebook profile page: ~140k
cnn.com: ~130k
Wikipedia article on "United States": ~135k

I did not compare to baseline memory costs for these pages (my test  
code only works in a debug build), and of course this is not going to  
be as accurate as doing real testing.

My test procedure was:

1) Apply this patch:

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: memory-use-estimate-data.patch.txt
Url: http://lists.webkit.org/pipermail/webkit-dev/attachments/20080930/0fa6d767/attachment.txt 
-------------- next part --------------



2) Build debug.
3) Launch Safari with the built WebKit, and visit a page to be tested.
4) Quit Safari; add up the three numbers dumped and multiply by 4.

I'm looking forward to more accurate data from Chrome folks, and some  
measurements or estimates of the potential speed gain.

Regards,
Maciej