Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Wed, Oct 1, 2008 at 10:41 PM, Mike Hommey [EMAIL PROTECTED][EMAIL PROTECTED] wrote: On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: Total size Potential savings www.cnn.com: 43M 410Kwww.facebook.com: 43M 408K www.slashdot.org: 36M 208K m.ext.google.com: 45M 475K docs (normal doc): 42M 341K docs (big spreadsheet):55M 905K maps: 38M 159K It would be interesting to have the figures on 64-bit systems. Why would it be different, since WebKit is (AFAIK) always compiled in 32-bit mode? Or is it 64-bit compat now? PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Thu, Oct 2, 2008 at 8:31 AM, Peter Kasting [EMAIL PROTECTED] wrote: On Wed, Oct 1, 2008 at 10:41 PM, Mike Hommey [EMAIL PROTECTED][EMAIL PROTECTED] wrote: On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: Total size Potential savings www.cnn.com: 43M 410Kwww.facebook.com: 43M 408K www.slashdot.org: 36M 208K m.ext.google.com: 45M 475K docs (normal doc): 42M 341K docs (big spreadsheet):55M 905K maps: 38M 159K It would be interesting to have the figures on 64-bit systems. Why would it be different, since WebKit is (AFAIK) always compiled in 32-bit mode? Or is it 64-bit compat now? WebKit compiles just fine in 64-bit. We even shiped it 32/64 fat on Leopard. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Oct 1, 2008, at 10:41 PM, Mike Hommey wrote: On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: Total size Potential savings www.cnn.com: 43M 410Kwww.facebook.com: 43M 408K www.slashdot.org: 36M 208K m.ext.google.com: 45M 475K docs (normal doc): 42M 341K docs (big spreadsheet):55M 905K maps: 38M 159K It would be interesting to have the figures on 64-bit systems. The extra space is all pointers so the size cost would double. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
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. Non-Node wrappers are another story. Perhaps they are all uncommon enough to go in a hash table. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Oct 1, 2008, at 1:46 AM, Geoffrey Garen 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. Depending on exactly how common they are, this could be more net memory use, if it causes Nodes to have a NodeRareData structure that wouldn't otherwise. 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. I think only a minority of nodes have wrappers, but on at least some pages it is likely to be a sizable minority. I did not measure though - should have. Non-Node wrappers are another story. Perhaps they are all uncommon enough to go in a hash table. I strongly suspect that is the case. On many of these sites, the number of CSSOM objects (inheriting from StyleBase) and NamedAttrMaps outnumbered the count of Nodes, and it is relatively rare to deal with such objects from JS. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Wed, Oct 1, 2008 at 1:46 AM, Geoffrey Garen [EMAIL PROTECTED] 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. -Sam ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
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. Depending on exactly how common they are, this could be more net memory use, if it causes Nodes to have a NodeRareData structure that wouldn't otherwise. 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. I think only a minority of nodes have wrappers, but on at least some pages it is likely to be a sizable minority. I did not measure though - should have. I should also mention Sam's suggestion, which I think is pretty good: All HTMLElements (or perhaps all Elements) get embedded pointers to their wrappers, since JavaScript traversal of a document is relatively common. All other DOM objects, including generic nodes, use a hash table. Geoff ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Wed, Oct 1, 2008 at 4:40 PM, Maciej Stachowiak [EMAIL PROTECTED] 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
tests.
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;
a.parentElement;
}
}
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
costs.
***
Again, I think the current memory cost is much higher than it needs to be,
so this tradeoff can become more favorable.
PK
___
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Oct 1, 2008, at 4:48 PM, Peter Kasting wrote: On Wed, Oct 1, 2008 at 4:40 PM, Maciej Stachowiak [EMAIL PROTECTED] wrote: Do we have any measurements of the performance benefit? Copying verbatim Feng's post on this from the other thread into this one: Oops, I missed that. 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. Sounds promising, though I'd like to see a test that combines some mutation with pure getters. It definitely sounds like it is worth experimenting with inline wrapper pointers only for selected classes, not for all RefCounted (or even for all bindable classes). Sounds like that could give a lot of the potential speed win, without nearly as much memory cost. Regards, Maciej ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Wed, Oct 1, 2008 at 4:30 PM, Peter Kasting [EMAIL PROTECTED] wrote: On Wed, Oct 1, 2008 at 4:03 PM, Mike Belshe [EMAIL PROTECTED] wrote: Also - Chrome currently taps into RefCountable and adds Peerable across any RefCountable object, whether it needs Peerable or not. Strings are an obvious example where we don't need Peer, and there are a lot of String objects. We took this tax in Chrome because we didn't want to fork further from Webkit, and we didn't see a better way to do it. We hope to correct this soon as we reconcile differences with WebKit. I bet this weighs pretty heavily in the memory figuring below. Without hard evidence, I'd suspect that just making things Peerable only if they need to be (not even including some of Maciej, Sam, et al.'s earlier suggestions on tuning that down even further) would slash the memory numbers below pretty noticeably. I think Mads already accounted for this, so the numbers below should be pretty accurate. For each RefCountable, we can save 8 bytes if we remove Peerable. For each TreeShared we can only save 4 bytes because TreeShared already has a vtable pointer. Mike, do you know if this is before or after the effort to chop the memory impact of Peerable by reducing the inherent overhead? Seems like those 8 bytes were going to get reduced to 4 (which would save noticeably)? I think this is our current implementation; so if we can do better than 8 bytes, it would be less. Total size Potential savings www.cnn.com: 43M 410K www.facebook.com: 43M 408K www.slashdot.org: 36M 208K m.ext.google.com: 45M 475K docs (normal doc): 42M 341K docs (big spreadsheet):55M 905K maps: 38M 159K My guess is that docs balloons so much between normal doc and big spreadsheet in large part because of the overhead of strings getting hit with this (although maybe it also creates lots more DOM nodes there). I guess the summary of all these comments from me is I strongly suspect that, if we remove the previous constraint of making as few changes as possible, we can slash these memory overhead numbers by at least 50% if not more. PK ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] JS binding wapper pointers: inline vs. separate hash table
On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: Total size Potential savings www.cnn.com: 43M 410Kwww.facebook.com: 43M 408K www.slashdot.org: 36M 208K m.ext.google.com: 45M 475K docs (normal doc): 42M 341K docs (big spreadsheet):55M 905K maps: 38M 159K It would be interesting to have the figures on 64-bit systems. Mike ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
