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

[Peter Kasting]

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.

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)?

                            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/d73d731a/attachment.html