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 >> 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 bet this weighs pretty heavily in the memory figuring below. Without > hard evidence, I'd suspect that just making things Peerable only if they > need to be (not even including some of Maciej, Sam, et al.'s earlier > suggestions on tuning that down even further) would slash the memory numbers > below pretty noticeably. > I think Mads already accounted for this, so the numbers below should be pretty accurate. > > 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. >> > > Mike, do you know if this is before or after the effort to chop the memory > impact of Peerable by reducing the inherent overhead? Seems like those 8 > bytes were going to get reduced to 4 (which would save noticeably)? > I think this is our current implementation; so if we can do better than 8 bytes, it would be less. > > 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 >> > > My guess is that docs balloons so much between "normal doc" and "big > spreadsheet" in large part because of the overhead of strings getting hit > with this (although maybe it also creates lots more DOM nodes there). > > I guess the summary of all these comments from me is "I strongly suspect > that, if we remove the previous constraint of making as few changes as > possible, we can slash these memory overhead numbers by at least 50% if not > more". > > PK >
_______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev