slow function call in V8 when using the same key for the functions in different objects

Question

Maybe not because the call is slow, but rather the lookup is; I'm not sure, but here is an example:

var foo = {};
foo.fn = function() {};

var bar = {};
bar.fn = function() {};

console.time('t');

for (var i = 0; i < 100000000; i++) {
    foo.fn();
}

console.timeEnd('t');

Tested on win8.1

• firefox 35.01: ~240ms
• chrome 40.0.2214.93 (V8 3.30.33.15): ~760ms
• msie 11: 34 sec
• nodejs 0.10.21 (V8 3.14.5.9): ~100ms
• iojs 1.0.4 (V8 4.1.0.12): ~760ms

Now here is the interesting part, if i change bar.fn to bar.somethingelse:

• chrome 40.0.2214.93 (V8 3.30.33.15): ~100ms
• nodejs 0.10.21 (V8 3.14.5.9): ~100ms
• iojs 1.0.4 (V8 4.1.0.12): ~100ms

Something went wrong in v8 lately? What causes this?

Answer 1

First fundamentals.

V8 uses hidden classes connected with transitions to discover static structure in the fluffy shapeless JavaScript objects.

Hidden classes describe the structure of the object, transitions link hidden classes together describing which hidden class should be used if a certain action is performed on an object.

For example the code below would lead to the following chain of hidden classes:

var o1 = {};
o1.x = 0;
o1.y = 1;
var o2 = {};
o2.x = 0;
o2.y = 0;

This chain is created as you construct o1. When o2 is constructed V8 simply follows established transitions.

Now when a property fn is used to store a function V8 tries to give this property a special treatment: instead of just declaring in the hidden class that object contains a property fn V8 puts function into the hidden class.

var o = {};
o.fn = function fff() { };

Now there is an interesting consequence here: if you store different functions into the field with the same name V8 can no longer simply follow the transitions because the value of the function property does not match expected value:

var o1 = {};
o1.fn = function fff() { };
var o2 = {};
o2.fn = function ggg() { };

When evaluating o2.fn = ... assignment V8 will see that there is a transition labeled fn but it leads to a hidden class that does not suitable: it contains fff in fn property, while we are trying to store ggg. Note: I have given function names only for simplicity - V8 does not internally use their names but their identity.

Because V8 is unable to follow this transition V8 will decide that its decision to promote function to the hidden class was incorrect and wasteful. The picture will change

V8 will create a new hidden class where fn is just a simple property and not a constant function property anymore. It will reroute the transition and also mark old transition target deprecated. Remember that o1 is still using it. However next time code touches o1 e.g. when a property is loaded from it - runtime will migrate o1 off the deprecated hidden class. This is done to reduce polymorphism - we don't want o1 and o2 to have different hidden classes.

Why is it important to have functions on the hidden classes? Because this gives V8's optimizing compiler information it uses to inline method calls. It can only inline method call if call target is stored on the hidden class itself.

Now lets apply this knowledge to the example above.

Because there is a clash between transitions bar.fn and foo.fn become normal properties - with functions stored directly on those objects and V8 can't inline the call of foo.fn leading to a slower performance.

Could it inline the call before? Yes. Here is what changed: in older V8 there was no deprecation mechanism so even after we had a clash and rerouted fn transition, foo was not migrated to the hidden class where fn becomes a normal property. Instead foo still kept the hidden class where fn is a constant function property directly embedded into the hidden class allowing optimizing compiler to inline it.

If you try timing bar.fn on the older node you will see that it is slower:

for (var i = 0; i < 100000000; i++) {
    bar.fn();  // can't inline here
}       

precisely because it uses hidden class that does not allow optimizing compiler to inline bar.fn call.

Now the last thing to notice here is that this benchmark does not measure the performance of a function call, but rather it measures if optimizing compiler can reduce this loop to an empty loop by inlining the call inside it.

Answer 2

Object literals share hidden class ("map" in v8 internal terms) by structure I.E. same named keys in same order, while objects created from different constructors would have different hidden class even if the constructors initialized them to exactly the same fields.

When generating code for foo.fn(), in the compiler you don't generally have access to the specific foo object but only its hidden class. From the hidden class you could access the fn function but because the shared hidden class can actually have different function at the fn property, that is not possible. So because you don't know at compile time which function will be called, you cannot inline the call.

If you run the code with trace inlining flag:

$ /c/etc/iojs.exe --trace-inlining test.js
t: 651ms

However if you change anything so that either .fn is always the same function or foo and bar have different hidden class:

$ /c/etc/iojs.exe --trace-inlining test.js
Inlined foo.fn called from .
t: 88ms

(I did this by doing bar.asd = 3 before the bar.fn-assignment, but there are a ton of different ways to achieve it, such as constructors and prototypes which you surely know are the way to go for high performance javascript)

To see what changed between versions, run this code:

var foo = {};
foo.fn = function() {};

var bar = {};
bar.fn = function() {};

foo.fn();
console.log("foo and bare share hidden class: ", %HaveSameMap(foo, bar));

As you can see the results differs between node10 and iojs:

$ /c/etc/iojs.exe --allow-natives-syntax test.js
foo and bare share hidden class:  true

$ node --allow-natives-syntax test.js
foo and bare share hidden class:  false

I haven't followed development of v8 in details recently so I couldn't point the exact reason but these kinds of heuristics change all the time in general.

IE11 is closed source but from everything they have documented it actually seems like it's very similar to v8.