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

Wed Oct 1 16:40:33 PDT 2008

Do we have any measurements of the performance benefit? In the absence  
of that, it's hard to judge the tradeoff. To me, 200k, 400k or even  
900k per page seems like extremey high memory overhead, though Mads  
apparently judged this to be not very high. With 50 tabs open, an  
average of 400k of overhead per page would be about 40M of extra  
memory use. Even 120k for a reasonable page (my lowball version of the  
estimate) seems like a nontrivial amount of memory. If we are talking  
speedups to realistic but tight code less than 1%, then it would seem  
to me not worth it. If we are talking 50% speedups, then it would  
almost certainly be worth it except maybe on highly memory-constrained  
platforms.

Is there any way to measure the speed benefit after the fact, even  
though it was not measured originally? It seems like we can't make a  
good decision based just on the memory stats.

Regards,
Maciej

On Oct 1, 2008, at 4:03 PM, Mike Belshe wrote:

> Maciej -
>
> Thanks for taking a look at this!
>
> First, a little history on this topic.  In Chrome, we call this  
> cached pointer interface "Peerable".  Originally, when we built  
> Peerable, it was not strictly for performance.  At that time we  
> hoped it would help us with breaking of circular references (we had  
> no hash map at all).  However, that plan changed, and at this point  
> the main benefit of Peerable is just the cached pointer.  There are  
> other differences between the JSC and V8 bindings; but they are  
> surmountable.  Anyway, because this has been an evolution and  
> because this wasn't originally just about performance, we don't have  
> a point in time where we added this interface and did strict before/ 
> after perf testing.
>
> 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 think Feng already posted the performance effects of Peerable.
>
> Regarding memory - I think your memory analysis looks reasonable.   
> Its a little lower than what we measured, but not out of whack.   
> Mads Ager did some measurements (he is out of town right now), and  
> here is what he had to say on the subject.
>
> In order to figure out how much extra space we use because of  
> Peerable, I have instrumented the test shell so that it prints  
> whenever a TreeShared or a RefCountable is constructed, destructed  
> and when it gets a non-null peer.  The reason for instrumenting  
> instead of measuring two different test_shells is that running  
> cnn.com multiple times varies in memory usage by over 10M (depending  
> on adds and other stuff) and I can't get reliable data that way.  I  
> have run this on a number of pages and calculated the potential  
> space savings.  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.
>
> Here is a short representation of the data (I have attached txt  
> files containing the data).  The total size is the total size of the  
> test_shell.exe process as shown in the Windows XP task manager.
>
>                             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
>
> The potential savings seem to be best-case:  I'm assuming that we  
> can remove Peerable without adding overhead anywhere else.
>
> To me, this indicates that the memory savings argument in favor of  
> removing Peerable is not very strong.
>
> Cheers,    -- Mads
>
>
>
> Mike
>
>
>
> On Wed, Oct 1, 2008 at 10:54 AM, Maciej Stachowiak <mjs at apple.com>  
> wrote:
>
> On Oct 1, 2008, at 10:50 AM, Geoffrey Garen wrote:
>
> >>> 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.
>
> That would probably cut the memory use significantly. On the other
> hand I bet there are some large pages where few of the nodes ever get
> a JS wrapper in the lifetime of the page (such as cnn.com, slashdot,
> or the Wikipedia page I cited).
>
> To make the right tradeoff we'll also need an estimate of the speed
> benefit.
>
> Regards,
> Maciej
>
> _______________________________________________
> webkit-dev mailing list
> webkit-dev at lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.webkit.org/pipermail/webkit-dev/attachments/20081001/063219e4/attachment.html 