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

Mike Belshe mike at belshe.com
Wed Oct 1 17:22:43 PDT 2008

On Wed, Oct 1, 2008 at 4:30 PM, Peter Kasting <pkasting at chromium.org> wrote:

> On Wed, Oct 1, 2008 at 4:03 PM, Mike Belshe <mike at belshe.com> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081001/4a643c5c/attachment.html 

More information about the webkit-dev mailing list