The benchmark:
JsPerf
The invariants:
var f = function() { };
var g = function() { return this; }
The tests:
Below in order of expected speed
new f;
g.call(Object.create(Object.prototype));
new (function() { })
(function() { return this; }).call(Object.create(Object.prototype));
Actual speed :
new f;
g.call(Object.create(Object.prototype));
(function() { return this; }).call(Object.create(Object.prototype));
new (function() { })
The question:
f
and g
for inline anonymous functions. Why is the new
(test 4.) test slower?Update:
What specifically causes the new
to be slower when f
and g
are inlined.
I'm interested in references to the ES5 specification or references to JagerMonkey or V8 source code. (Feel free to link JSC and Carakan source code too. Oh and the IE team can leak Chakra source if they want to).
If you link any JS engine source, please explain it.
The main difference between #4 and all other cases is that the first time when you use a closure as a constructor is always quite expensive.
It is always handled in V8 runtime (not in generated code) and transition between compiled JS code and C++ runtime is quite expensive. Subsequent allocations usually are handled in generated code. You can take a look at Generate_JSConstructStubHelper
in builtins-ia32.cc
and notice that is falls through to the Runtime_NewObject
when closure has no initial map. (see http://code.google.com/p/v8/source/browse/trunk/src/ia32/builtins-ia32.cc#138)
When closure is used as a constructor for the first time V8 has to create a new map (aka hidden class) and assign it as an initial map for that closure. See http://code.google.com/p/v8/source/browse/trunk/src/heap.cc#3266. Important thing here is that maps are allocated in a separate memory space. This space can't be cleaned by a fast partial scavenge collector. When map space overflows V8 has to perform relatively expensive full mark-sweep GC.
There are couple of other things happening when you use closure as a constructor for the first time but 1 and 2 are the main contributors to the slowness of test case #4.
If we compare expressions #1 and #4 then differences are:
If we compare #3 and #4 then differences are:
Bottom line here is that the first time you use closure as a constructor is expensive compared to subsequent construction calls of the same closure because V8 has to setup some plumbing. If we immediately discard the closure we basically throw away all the work V8 has done to speedup subsequent constructor calls.
The problem is that you can inspect the current source code of various engines, but it won't help you much. Don't try to outsmart the compiler. They'll try to optimize for the most common usage anyway. I don't think (function() { return this; }).call(Object.create(Object.prototype))
called 1,000 times has a real use-case at all.
"Programs should be written for people to read, and only incidentally for machines to execute."
Abelson & Sussman, SICP, preface to the first edition
I guess the following expansions explain what is going on in V8:
t(exp4) : t(Object Creation) + t(Function Object Creation) + t(Class Object Creation)[In Chrome]
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With