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

[Mike Belshe]

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