Are frozen Objects faster ?

[Andrea Giammarchi]

that is assuming nobody ever call the constructor without new keyword and
no inheritance is involved, since the sub constructor would be trapped
behind the parent.

That would be even more magic ... I kinda like it, not sure is explicit
enough though ... but yeah, if freeze(this) would do that, it would be
awesome!


On Thu, Feb 14, 2013 at 12:50 PM, Kevin Gadd <kevin.gadd at gmail.com> wrote:

> Ideally the JIT would, at runtime, just identify the pattern where
> your constructor ends with an Object.freeze(this) call, and turn it
> into the equivalent of an immutable, pass-by-value packed struct. IIRC
> v8 and SpiderMonkey are both able to do some of this already based on
> looking at your constructor and using shape information...
>
> -kg
>
> On Thu, Feb 14, 2013 at 12:49 PM, Andrea Giammarchi
> <andrea.giammarchi at gmail.com> wrote:
> > 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/d3afed6b/attachment.html>