Vyacheslav, When I run the code you posted, I see a much bigger discrepancy between test/test2 in the first pass and a slight reduction in test's time but still a large discrepancy the second pass (indicating OSR happened during the first loop the first time around), similar to what I was seeing yesterday. But that's running on Node.js, and I haven't re-built Node.js against the latest stable v8 code, but that issue is completely gone in the current nightly Canary build.
I think I better understand the method issue now. V8 actually treats methods set on this. differently than other properties, the assembly generated looks aggressively inlined. If you cheat and set this.test to a number then to the method, it effectively disables those optimizations in V8 and you end up treating the object as a normal object, and even though it doesn't cause deoptimizations (all objects have the same hidden class), it's significantly slower than the inlined method call. The real issue in my example is that test is per- object and runTest is static, if runTest was assigned via this., it should only ever see one hidden class, unless you do something evil like .apply. Though this test seems to indicate that this only occurs when building the hidden class: http://pastebin.com/JbuLaEUt Even though it never deoptimizes, I'd expect each of those to have similar performance, but only the first Foobar created is performant. On a related note, has there been any consideration for making v8 not de-optimize when a hidden class is ancestral to another (and therefore compatible)? I mean if you have {a: 7, b: 7} and you have a really hot loop that only touches a and b, then you add a c property, because it was transitioned from the proper hidden class for that hot loop to a superclass of it (with the same indices in its property access table), that hot function can assume it's the {a, b} hidden class. This is similar to how classical inheritance works (Foo extends Bar, functions that operate on Bar can also operate on Foo), but in this case a hidden class transition is a strict superset, which lets you make really nice assumptions. On Jul 19, 2:27 am, Vyacheslav Egorov <[email protected]> wrote: > Hi Justin, > > V8's hidden classes are not limited to tracking fields you assign to > an object, V8 also tries to capture methods you assign (just like in > any object-oriented language classes capture both data and behavior). > > That is why first and second objects produced by Foobar will have > different hidden classes --- they have different methods. > > As to your second question: they are not treated differently. If you > rewrite your test like this: > > var z = {test: function () {}}; > z.test2 = function () {}; > > function foo(z) { > var i; > console.time('test speed'); > for (i = 0; i < 10000000; i++) z.test(); > console.timeEnd('test speed'); > console.time('test2 speed'); > for (i = 0; i < 10000000; i++) z.test2(); > console.timeEnd('test2 speed'); > > } > > foo(z); > foo(z); > > You will see something like: > > test speed: 38ms > test2 speed: 12ms > test speed: 11ms > test2 speed: 11ms > > Truth is V8 optimizes the code while the first loop is still _running_ > (this is called On Stack Replacement aka OSR). So first "test speed" > measurement contains a sum of time spent in unoptimized code, compiler > and optimized code and first "test2 speed" measurement is purely time > spent in optimized code. If you call the same code second time you see > purely timing results for optimized code. This is why benchmarks > should always contain warm up phase to let optimizing JIT kick in. > > Hope this explains it. > > -- > Vyacheslav Egorov > > > > > > > > On Thu, Jul 19, 2012 at 3:04 AM, jMerliN <[email protected]> wrote: > > So I can't get my head around why this happens (I haven't dug through > > v8's code to try to figure it out either), but this is really > > inconsistent to me with how v8 constructs hidden classes in general. > > The following is running in Node.js v0.8.2 (V8 v3.11.10.12). > > > Here's the code: > >http://pastebin.com/2gKWrfHp > > > Here's the output, and the deopt trace: > >http://pastebin.com/WerQuGLZ > > > Calling Foo.prototype.runTest with any Foo object results in similar > > performance (unless you change the hidden class, as expected). Bar > > expectedly deoptimizes because abc is stored on the proto and isn't > > actually on the constructed object until the first call, causing the > > optimized function (once it gets hot, which is after the object has > > changed hidden class) to bailout on the next attempt with a new Bar > > object. > > > It gets weird with Foobar. test is added directly to the object, the > > only difference is that this is a function, not a primitive, but it > > seems like the hidden classes of objects from Foobar's constructor > > should be the same. The first run is performant, equivalent to Foo > > (expected). Though running the test again with a new Foobar > > deoptimizes it. I can't at all understand why. > > > Thanks, > > Justin > > > -- > > v8-users mailing list > > [email protected] > >http://groups.google.com/group/v8-users -- v8-users mailing list [email protected] http://groups.google.com/group/v8-users
