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:
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 Potential savings
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
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
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
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 wrappers
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
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
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
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 an
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
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
12 matches
Mail list logo
