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