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 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
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 <[EMAIL PROTECTED]> 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@lists.webkit.org
> http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
>
_______________________________________________
webkit-dev mailing list
webkit-dev@lists.webkit.org
http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
