<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>Regards,</div><div>Maciej</div><br><div><div>On Oct 1, 2008, at 4:03 PM, Mike Belshe wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Maciej -<div><br></div><div>Thanks for taking a look at this! </div><div><br></div><div>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. </div> <div><br></div><div>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.</div> <div><br></div><div>I think Feng already posted the performance effects of Peerable.</div><div><br></div><div>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. </div> <div><br></div><div><span class="Apple-style-span" style="border-collapse: collapse; ">In order to figure out how much extra space we use because of <span class="nfakPe" style="background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: rgb(255, 255, 136); background-position: initial initial; ">Peerable</span>, 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 <a href="http://cnn.com/" target="_blank" style="color: rgb(0, 0, 204); ">cnn.com</a> 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 <span class="nfakPe" style="background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: rgb(255, 255, 136); background-position: initial initial; ">Peerable</span>. For each TreeShared we can only save 4 bytes because TreeShared already has a vtable pointer.<br> <br>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.<br><br><div><span> Total size Potential savings</span><br> <span><a href="http://www.cnn.com/" target="_blank" style="color: rgb(0, 0, 204); ">www.cnn.com</a>: 43M 410K</span><div><span style="font-size: 12px; "><a href="http://www.facebook.com/" target="_blank" style="color: rgb(0, 0, 204); ">www.facebook.com</a>: 43M 408K</span></div> <div><span style="font-size: 12px; "><a href="http://www.slashdot.org/" target="_blank" style="color: rgb(0, 0, 204); ">www.slashdot.org</a>: 36M 208K</span></div><div><span style="font-size: 12px; "><a href="http://m.ext.google.com/" target="_blank" style="color: rgb(0, 0, 204); ">m.ext.google.com</a>: 45M 475K</span></div> <div><span style="font-size: 12px; ">docs (normal doc): 42M 341K</span></div><div><span style="font-size: 12px; ">docs (big spreadsheet): 55M 905K</span></div><div> <span style="font-size: 12px; ">maps: 38M 159K</span></div><div><br></div><div>The potential savings seem to be best-case: I'm assuming that we can remove <span class="nfakPe" style="background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: rgb(255, 255, 136); background-position: initial initial; ">Peerable</span> without adding overhead anywhere else.</div> <div><br></div><div>To me, this indicates that the memory savings argument in favor of removing <span class="nfakPe" style="background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: rgb(255, 255, 136); background-position: initial initial; ">Peerable</span> is not very strong.</div> <div><br></div><div>Cheers, -- <span class="nfakPe" style="background-image: initial; background-repeat: initial; background-attachment: initial; -webkit-background-clip: initial; -webkit-background-origin: initial; background-color: rgb(255, 255, 136); background-position: initial initial; ">Mads</span></div> </div></span></div><div><br></div><div><br></div><div><br></div><div><span style="border-collapse:collapse">Mike</span></div><div><span style="border-collapse:collapse"><br> </span></div><div><br><br><div class="gmail_quote">On Wed, Oct 1, 2008 at 10:54 AM, Maciej Stachowiak <span dir="ltr"><<a href="mailto:mjs@apple.com" target="_blank">mjs@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div><br> On Oct 1, 2008, at 10:50 AM, Geoffrey Garen wrote:<br> <br> >>> If we believe that JS wrappers are relatively uncommon, we can<br> >>> store them in a Node's "rare data" structure, and bloat only those<br> >>> uncommon nodes that have JS wrappers.<br> >><br> >> Depending on exactly how common they are, this could be more net<br> >> memory use, if it causes Nodes to have a NodeRareData structure<br> >> that wouldn't otherwise.<br> >><br> >>> If we believe that JS wrappers are relatively common, we can store<br> >>> them directly in a Node, since putting them in a hashtable is net<br> >>> more memory use.<br> >><br> >> I think only a minority of nodes have wrappers, but on at least<br> >> some pages it is likely to be a sizable minority. I did not measure<br> >> though - should have.<br> ><br> > I should also mention Sam's suggestion, which I think is pretty<br> > good: All HTMLElements (or perhaps all Elements) get embedded<br> > pointers to their wrappers, since JavaScript traversal of a document<br> > is relatively common. All other DOM objects, including generic<br> > nodes, use a hash table.<br> <br> </div>That would probably cut the memory use significantly. On the other<br> hand I bet there are some large pages where few of the nodes ever get<br> a JS wrapper in the lifetime of the page (such as <a href="http://cnn.com" target="_blank">cnn.com</a>, slashdot,<br> or the Wikipedia page I cited).<br> <br> To make the right tradeoff we'll also need an estimate of the speed<br> benefit.<br> <br> Regards,<br> <font color="#888888">Maciej<br> </font><div><div></div><div><br> _______________________________________________<br> webkit-dev mailing list<br> <a href="mailto:webkit-dev@lists.webkit.org" target="_blank">webkit-dev@lists.webkit.org</a><br> <a href="http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev" target="_blank">http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev</a><br> </div></div></blockquote></div><br></div></div></blockquote></div><br></body></html>