Are frozen Objects faster ?

[Andrea Giammarchi]

One more thought ... the best scenario **ever** would be the ability to
define a frozen prototype and create already fixed shaped instance at
runtime.

I think Object.freeze() semantic is not the right one to do this, but I am
dreaming about something like this:

var MyStaticShapeConstructor = Object.createStaticConstructor(
  inheritFrom, // either null or actually not extremely important
  descriptors // descriptors we know
);

var instance = new MyStaticShapeConstructor;

We might discuss if the "constructor" property in descriptors should have a
handy, exceptional, treatment (ie invoked with arguments)

{
  constructor: {
    value: function (a, b, c) {
      // invoked when new MyStaticShapeConstructor(1,2,3)
    }
  }
}

 or simply encourage the usage of o.init(arg1, ..., argN);

I know this is way too much magic behind the scene but it would be straight
forward from different points of view, at least for JS users, IMHO, and
really easy to polyfill.

Thoughts on this would be much appreciated, thanks.

Apologies if already discussed and I have missed that thread.

br



On Thu, Feb 14, 2013 at 12:36 PM, Andrea Giammarchi <
andrea.giammarchi at gmail.com> wrote:

> the `delete obj.property` changes the shape of the object, right? so I
> think is more a problem of devs using objects as trash bin but this is the
> opposite scenario of a frozen object.
>
> I understand ES5 descriptors are an overhead during an object lifecycle
> but I think a mechanism to make frozen object that fast would be a win
> while we wait for better options on statically defined types.
>
> "Binary Arrays" are indeed frozen objects, at least in Firefox, and ultra
> fast:
> Object.isFrozen(new Float32Array()) // true in Firefox
>
> Since these are ultra fast in Chrome too but not frozen, I believe there
> is already a way to speed up typed stuff (didn't check how it's done
> though) so I wonder how come Object.freeze() is not taking similar approach
> "typizing" behind the scene the object improving all static properties
> getters (probably dropping those getters where possible unless defined as
> such)
>
> Will this cost more than now at freeze() time? I understand this might be
> undesired but think about libraries or modules that do not want to be
> extended, would like to be as fast as possible, and are loaded once and
> never again.
>
> Thanks for all thoughts and info already provided, also agreed on some
> bench.
> I usually do that on jsPerf 'cause I don't know how to reach those bigger,
> widely tested, one.
>
> Any hint here appreciated.
>
>
>
>
>
> On Thu, Feb 14, 2013 at 12:24 PM, Andreas Rossberg <rossberg at google.com>wrote:
>
>> On 14 February 2013 21:12, Kevin Gadd <kevin.gadd at gmail.com> wrote:
>> > I'm pleased to report that Object.freeze does not seem to cause an
>> > enormous performance hit in v8 anymore. Hooray! Unfortunately, the
>> > call to Object.freeze itself shows up as a bottleneck in V8 profiles,
>> > and the 'freeze enabled' version is slower in both versions (though at
>> > least only slightly slower).
>>
>> Thanks for doing the benchmark, very interesting!
>>
>> That freeze bottleneck will hopefully vanish in the foreseeable future.
>>
>> /Andreas
>> _______________________________________________
>> 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/20130214/456b4ed1/attachment-0001.html>