Are frozen Objects faster ?

[Andrea Giammarchi]

not sure I follow here ... I did ask if Object.freeze was faster and why,
if not, 'cause faster is what I would expect after a probably slower
operation as freeze could be.

Aymeric yes, that was unfortunate, also I don't understand all these
different behaviors but point is, I think you can extend in Chrome, you
cannot in Firefox and no idea why this choice (bu tI understand the
implementation of static, fixed, type/shape)

So, it looks like is planned, but nobody knows when? Well, that's better
than nothing :-)




On Fri, Feb 15, 2013 at 4:09 AM, Alex Russell <slightlyoff at google.com>wrote:

> On Thursday, February 14, 2013, Andreas Rossberg wrote:
>
>> On 14 February 2013 19:26, Herby Vojčík <herby at mailbox.sk> 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 at mozilla.org
> https://mail.mozilla.org/listinfo/es-discuss
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/es-discuss/attachments/20130215/7b7c2a6e/attachment.html>