Are frozen Objects faster ?

[Alex Russell]

On Thursday, February 14, 2013, Andreas Rossberg wrote:

> On 14 February 2013 19:26, Herby Vojčík <herby at 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!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130215/7be7bd90/attachment.html>