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

2008-10-02 Thread Maciej Stachowiak
On Oct 2, 2008, at 11:14 AM, Mike Hommey wrote: > On Thu, Oct 02, 2008 at 11:06:19AM -0700, Maciej Stachowiak wrote: >> >> On Oct 1, 2008, at 10:41 PM, Mike Hommey wrote: >> >>> On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: Total size Potent

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

2008-10-02 Thread Mike Hommey
On Thu, Oct 02, 2008 at 11:06:19AM -0700, Maciej Stachowiak wrote: > > On Oct 1, 2008, at 10:41 PM, Mike Hommey wrote: > >> On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: >>>Total size Potential savings >>> www.cnn.com: 43M

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

2008-10-02 Thread Maciej Stachowiak
On Oct 1, 2008, at 10:41 PM, Mike Hommey wrote: > On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: >>Total size Potential savings >> www.cnn.com: 43M >> 410Kwww.facebook.com: >> 43M

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

2008-10-02 Thread Sam Weinig
On Thu, Oct 2, 2008 at 8:31 AM, Peter Kasting <[EMAIL PROTECTED]> wrote: > On Wed, Oct 1, 2008 at 10:41 PM, Mike Hommey <[EMAIL PROTECTED]<[EMAIL > PROTECTED]> > > wrote: > >> On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: >> > Total size Potent

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

2008-10-02 Thread Peter Kasting
On Wed, Oct 1, 2008 at 10:41 PM, Mike Hommey <[EMAIL PROTECTED]<[EMAIL PROTECTED]> > wrote: > On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: > > Total size Potential savings > > www.cnn.com: 43M > 410Kwww.facebook.com: > >

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

2008-10-01 Thread Mike Hommey
On Wed, Oct 01, 2008 at 04:03:32PM -0700, Mike Belshe wrote: > Total size Potential savings > www.cnn.com: 43M 410Kwww.facebook.com: > 43M 408K > www.slashdot.org: 36M

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

2008-10-01 Thread Mike Belshe
On Wed, Oct 1, 2008 at 5:03 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > > On Oct 1, 2008, at 4:48 PM, Peter Kasting wrote: > > On Wed, Oct 1, 2008 at 4:40 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > >> Do we have any measurements of the performance benefit? >> > > Copying verbatim Fe

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

2008-10-01 Thread Mike Belshe
On Wed, Oct 1, 2008 at 4:30 PM, Peter Kasting <[EMAIL PROTECTED]> wrote: > On Wed, Oct 1, 2008 at 4:03 PM, Mike Belshe <[EMAIL PROTECTED]> wrote: > >> Also - Chrome currently taps into RefCountable and adds Peerable across >> any RefCountable object, whether it needs Peerable or not. Strings are

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

2008-10-01 Thread Maciej Stachowiak
On Oct 1, 2008, at 4:48 PM, Peter Kasting wrote: On Wed, Oct 1, 2008 at 4:40 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: Do we have any measurements of the performance benefit? Copying verbatim Feng's post on this from the other thread into this one: Oops, I missed that. These No

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

2008-10-01 Thread Peter Kasting
On Wed, Oct 1, 2008 at 4:40 PM, Maciej Stachowiak <[EMAIL PROTECTED]> wrote: > Do we have any measurements of the performance benefit? > Copying verbatim Feng's post on this from the other thread into this one: *** I did some performance measurement a few weeks ago. I made a version of Chrome w

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

2008-10-01 Thread Maciej Stachowiak
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

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

2008-10-01 Thread Peter Kasting
On Wed, Oct 1, 2008 at 4:03 PM, Mike Belshe <[EMAIL PROTECTED]> 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 >

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

2008-10-01 Thread Mike Belshe
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

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

2008-10-01 Thread Maciej Stachowiak
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

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

2008-10-01 Thread Geoffrey Garen
>> 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 Node

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

2008-10-01 Thread Sam Weinig
On Wed, Oct 1, 2008 at 1:46 AM, Geoffrey Garen <[EMAIL PROTECTED]> wrote: > > In the Chrome tree, every object inheriting from RefCounted incurs > > an extra pointer in size, but this is clearly more than necessary > > since many RefCounted objects do not have bindings. > > If we believe that JS w

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

2008-10-01 Thread Maciej Stachowiak
On Oct 1, 2008, at 1:46 AM, Geoffrey Garen wrote: >> In the Chrome tree, every object inheriting from RefCounted incurs >> an extra pointer in size, but this is clearly more than necessary >> since many RefCounted objects do not have bindings. > > If we believe that JS wrappers are relatively

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

2008-10-01 Thread Geoffrey Garen
> In the Chrome tree, every object inheriting from RefCounted incurs > an extra pointer in size, but this is clearly more than necessary > since many RefCounted objects do not have bindings. If we believe that JS wrappers are relatively uncommon, we can store them in a Node's "rare data" str

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

2008-09-30 Thread Maciej Stachowiak
One of the changes in Chrome's version of WebKit is that, instead of storing pointers to the JS binding object for a core object in a HashMap, it stores them directly in the core object. Although this change is not currently in the webkit.org tree, and is in the Chrome tree for the V8 bin