782906 - Improve performance of Object.create

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect)

Description

[Katelyn Gadd (:kael)]

Right now, Object.create is dramatically slower than calling new on an equivalent empty constructor. It's fine that constructors get optimized more than if you were to call create and then set properties, but the fact that create is so suboptimal performance-wise means that it's actually faster to use a JS polyfill in many cases.

To give a concrete example, JSIL has a runtime function that implements cloning for structs. I used to do it by calling Object.create on the prototype for the struct, then copying member values from the instance being cloned to the new, empty instance. Profiling this in FF showed a large amount of CPU time just being spent executing Object.create (it looks like it relies on a stub?). Replacing it with the (relatively nasty) polyfill:

var copyConstructor = function (source) {
  // copy the members
  this.foo = source.foo;
  ...
};
copyConstructor.prototype = theType.prototype;

Dramatically improved performance. I don't know how common use of Object.create actually is in the wild, but it would at least be nice if it was closer to the perf of the polyfill.

Comment 1

[Katelyn Gadd (:kael)]

Oh, I forgot:

Part of why this matters is that in the general case, the polyfill will be worse. This is because the polyfill can't be fully general without creating an entirely new constructor function (and setting its prototype) every time you create an instance, unless it does some sort of insane caching shenanigans. So it should be pretty trivial to beat the polyfill in the general case.

Comment 2

[Luke Wagner [:luke]]

IIRC, v8 is also tremendously slow on Object.create?

Comment 3

[Katelyn Gadd (:kael)]

Based on http://jsperf.com/new-vs-object-create/6 I believe they are, yes. I'm not sure if their reason for it is the same, though.

Comment 4

[Till Schneidereit [:till]]

Not only are we faster than Chrome (27, ~6x) and Safari (6.0.5, ~1.1x), we are, weirdly, also more than twice as fast at the `Object.create` test as on the `new` test.

While I don't know why that is and we should obviously work on making the `new` test faster, I'm going to declare victory here.

Comment 5

[Katelyn Gadd (:kael)]

Object.create isn't faster in FF, that's just jsperf being terrible and getting entirely optimized out.

http://jsperf.com/new-vs-object-create/12

I modified the test to make it harder to optimize out and now 'new' is faster just like before (unless I made a mistake). I just recently replaced an 'Object.create' in a JSIL library with 'new' and saw a speed improvement in FF, so I'm pretty sure this isn't actually fixed.

Comment 6

[Till Schneidereit [:till]]

Urgh. So, if it gets optimized out, how come we're still an order of a magnitude slower than the competition is with the `new Klass()` case?

Anyway, with today's Nightly, with your modified test the `Object.create()` version is still 50% faster for me.


I'm pretty much done with jsperf at this point, so prepare for gistbench[1], with sandboxed srcdoc'd iframes[2] to create low-overhead, predictable benchmarks.

[1]: working title
[2]: with rawgithub.com-fallback for browsers without srcdoc support. Such as us before the Nightly released later today

Comment 7

[Mayank Bansal]

Closing this bug as anything shuway or JSIL is not a priority these days. And code like this should target WASM these days.