Was talking with @jdalton tonight at the Seattle JS meetup about lodash (his presentation on it will hopefully be available soon), and how it unexpectedly creams the performance of the native versions of the functions it implements.
lodash has a (significant) performance boost where it checks whether a function uses
this to determine if it can use
f() instead of
f.call(). Right now jdalton has this shimmed with
/\bthis\b/.test(f.toString()), which is very hacky (with some environments not even supporting function stringification at all). If this were made available, lodash could just check
The way lodash determines this right now is by comparing with something like
Object.prototype.toString.toString(), which is only slightly less unreliable than the above hack for testing the existence of a reference.
I think there was also some mention of surfacing a flag for native objects (eg. DOM elements) as well.
lodash is currently designed to assume that an array is never sparse. Exposing this would let lodash implement a slow-path for sparse array compatibility, and subsequently / conversely open the door for performant shims of existing sparse-array-compatible core functions.
I’m not sure where this could go or what the interface / signature should be, but jdalton mentioned that his work would be significantly easier (as it would certainly be for many other developers, myself included) if VMs exposed the deep object clone method they use for places like
(Edit: replaced Function#references with Function#isBound per @FremyCompany’s suggestion)