On Sun, Mar 6, 2016 at 7:28 PM, Phil Bouchard <philipp...@gmail.com> wrote: > On 03/06/2016 10:17 PM, Filip Pizlo wrote: >> >> >>> On Mar 6, 2016, at 6:36 PM, Phil Bouchard <philipp...@gmail.com> wrote: >>> >>> That should speed up my benchmarking process. >> >> >> It will also make your benchmarking process inconclusive for the purpose >> of evaluating a memory manager’s performance relative to our garbage >> collector. To put it another way, I don’t care if your memory manager is >> faster than someone else’s garbage collector. > > > It is very subjective but if we know that: > - WebKit's GC is 2x faster than the Mark & Sweep GC > - block_ptr<> is 2x faster than the Mark & Sweep GC > > Then that means WebKit's GC == block_ptr<>.
No :( It's pretty relevant that GC in JavaScriptCore was written for JavaScriptCore. In particular, JSC doesn't focus on optimizing binary size, memory usage, etc... for embeddable devices so I would expect the performance characteristics to be dramatically different from that of Duktape or XS6. Analyzing the performance of a computer software is really hard. I've been working on WebKit for six and half years and I'm still surprised by the kind of performance issues we encounter and the difference in the performance characteristics between different CPU architectures, the number of cores, and the spec of a particular CPU. - R. Niwa _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org https://lists.webkit.org/mailman/listinfo/webkit-dev
