Cool. I don't claim to fully understand this, but as I read your issue, it seems the optimization could/would apply to either spread properties OR `Object.assign` case. If that's true, then there's nothing specially optimizable about spread properties, in which case that particular point would NOT have been a reason to support its adoption. Or is there some nuance I'm missing?
On Tue, Feb 13, 2018 at 4:58 PM, Isiah Meadows <[email protected]> wrote: > BTW, regarding engine optimizability of those, I've filed a couple V8 bugs: > > - https://bugs.chromium.org/p/v8/issues/detail?id=7435 (object spread > + `Object.assign`) > - https://bugs.chromium.org/p/v8/issues/detail?id=7436 (array spread + > `Array.prototype.concat`) > > There are things engines *could* do that they *aren't currently > doing*. Part of why I proposed V8 take a look at this is because it > has one of the more flexible IC systems out of all the engines (they > can lower `Array.prototype.map` to a simple loop for dense arrays even > though a simple `delete array[index]` within the loop breaks the > assumption - this is *exceptionally* difficult to implement with the > ability to deoptimize). > ----- > >
_______________________________________________ es-discuss mailing list [email protected] https://mail.mozilla.org/listinfo/es-discuss
