Are frozen Objects faster ?

Kevin Gadd kevin.gadd at
Thu Feb 14 12:50:55 PST 2013

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...


On Thu, Feb 14, 2013 at 12:49 PM, Andrea Giammarchi
<andrea.giammarchi at> 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> wrote:
>> the `delete` 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>
>> wrote:
>>> On 14 February 2013 21:12, Kevin Gadd <kevin.gadd at> 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

More information about the es-discuss mailing list