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
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
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
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
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:
> >
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
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
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
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
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
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
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
>
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
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
>> 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
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
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
> 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
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
19 matches
Mail list logo
