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.giammar...@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.giammar...@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 <rossb...@google.com>
>> wrote:
>>>
>>> On 14 February 2013 21:12, Kevin Gadd <kevin.g...@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@mozilla.org
>>> https://mail.mozilla.org/listinfo/es-discuss
_______________________________________________
es-discuss mailing list
es-discuss@mozilla.org
https://mail.mozilla.org/listinfo/es-discuss
