On Thursday, February 14, 2013, Andreas Rossberg wrote: > On 14 February 2013 19:26, Herby Vojčík <he...@mailbox.sk <javascript:;>> > wrote: > > I meant "de facto". People wanting to remove property bar from foo do not > > write `delete foo.bar` anymore; they (at least some significant subset) > have > > learned to write `foo.bar = null;` or `foo.bar = undefined;`. The reason > is > > perf - `delete` deoptimized hidden classes. > > And with ES6, those people will hopefully realise that for those > cases, using a Map is a cleaner alternative anyway. >
I think it's worth noting here that *of course* older features have seen heavier optimization. I honestly expect that the Map type will start much slower than it will eventually end up being, perhaps not in V8, but elsewhere. But slow and available often beats unavailable and/or non-standard. It's a complicated story to tell end-users, but anything else is misleading. One hopes that any new feature we that gets wide implementation and is not explicitly performance oriented pays for itself on a semantic basis. Such features find their natural users prior to the optimization foot race kicking off, and there's nothing bad about any of that. The ideal world (that freeze() is now a poster child for) looks roughly like: // Standard written, implementations arrive (not in that order) // ...time passes... Hooray! New features! // ...time passes... // Users realize optimization is uneven Boo! They're slow! // Said without any sense of JS perf history // ...time passes... // Features optimized Yay! They're fast!
_______________________________________________ es-discuss mailing list es-discuss@mozilla.org https://mail.mozilla.org/listinfo/es-discuss
