Why is new slow?

by

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.

  1. 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)

  2. 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:

  • #1 does not allocate a new closure every time;
  • #1 does not enter runtime every time: after closure gets initial map construction is handled in the fast path of generated code. Handling the whole construction in generated code is much faster then going back and forth between runtime and generated code;
  • #1 does not allocate a new initial map for each new closure every time;
  • #1 does not cause a mark-sweeps by overflowing map space (only cheap scavenges).

If we compare #3 and #4 then differences are:

  • #3 does not allocate a new initial map for each new closure every time;
  • #3 does not cause a mark-sweeps by overflowing map space (only cheap scavenges);
  • #4 does less on JS side (no Function.prototype.call, no Object.create, no Object.prototype lookup etc) more on C++ side (#3 also enters runtime every time you do Object.create but does very little there).

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.

Leave a Comment