Re-optimize ES.TypeIsObject.
#388
Conversation
|
lulz @ js engine optimization |
| // http://www.ecma-international.org/ecma-262/6.0/#sec-toobject | ||
| // but is not well optimized by runtimes and creates an object | ||
| // whenever it returns false, and thus is very slow. | ||
| return typeof x === 'function' || typeof x === 'object'; |
There was a problem hiding this comment.
fwiw i think we could do || Object(x) === x here and only new primitives would hit the slow path, and only until we'd attempted to account for them - that might be better than leaving just the comment?
There was a problem hiding this comment.
That's an interesting proposal. You'd have to add back the string/number/symbol checks in that case, though, to ensure that only "exotics" hit the || Object(x) case. Not sure the extra complexity is worth it, given that I can't actually identify any valid "exotics" in any implementation that don't return 'object' or 'function'. Presumably if there really is some instance in the wild someone will file a bug complaining that es6-shim throws a TypeError in some case when it shouldn't, and we can tweak the check then.
There was a problem hiding this comment.
ah yes, i missed that you removed those.
That's a fair point, so I think this is OK
Caching the typeof value in a local variable defeats the `typeof x === <constant string>` peephole optimization, and slows down es6-shim on the doxbee benchmark (on my machine, 20000 iterations) from 5870ms (with this patch) to 6062ms (without it).
cscott
force-pushed
the
typeisobject-performance
branch
from
eff224a
to
7534f16
Compare
[Refactor] Re-optimize `ES.TypeIsObject`
Caching the typeof value in a local variable defeats the
typeof x === <constant string>peephole optimization, and slows downes6-shimon the doxbee benchmark (on my machine, 20000 iterations) from 5870ms (with this patch) to 6062ms (without it).