Performance of property access after Object.freeze

[th...@kode4food.it]

I'm seeing this in Node, but can only assume it's V8 related.

Can anyone explain to me why reading an Object's property is considerably slower after calling Object.freeze against that object?

It appears to be about 5+ times slower.

Thanks,

Thom

[Jakob Kummerow]

Works for me:

not frozen: 1061 ms

frozen: 1054 ms

There were some Object.freeze optimizations a couple of months ago. Maybe you're running a very old revision?

--
--
v8-dev mailing list
v8-...@googlegroups.com
http://groups.google.com/group/v8-dev
---
You received this message because you are subscribed to the Google Groups "v8-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to v8-dev+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Thom Bradford]

Whatever is latest on Chris Lea's PPA

You received this message because you are subscribed to a topic in the Google Groups "v8-dev" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/v8-dev/NBn7xwusqDI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to v8-dev+un...@googlegroups.com.

[Jakob Kummerow]

Well, as long as you're stuck with a version dating back to roughly the ice age, don't freeze your objects, problem solved.

[Thomas Bradford]

Not sure if “don’t freeze objects” as punishment for using an older version of v8 solves the problem, especially if a person’s intent is to prohibit mutation. 

So back to my original question, because I think it’s important to understand.  Why *was* it 5+ times slower?  In the best case, reading a frozen property should be slightly faster.  In the worst case it should be exactly the same speed.  (Object.freeze, should only intercept writes in an ideal world).   Such a performance hit doesn’t make sense unless something horribly wrong was going on in the implementation.

I’d just like to understand it.  I suppose I could look at the diffs, but that doesn’t explain why it was written the way it was to begin with.

--
Thomas Bradford
@Kode4Food

[Jakob Kummerow]

I don't see why it's important to understand why things were slow two years ago -- on the contrary, I'd call it a waste of time for both of us.

Frozen objects are a special case, special cases tend to be slower unless someone decides to optimize them. Specifically, freezing an object used to turn it into a slow (a.k.a. "dictionary") representation internally, because only the slow representation was able to encode the fact that the object was frozen.

Try not to have too specific performance expectations from JavaScript implementations. It's a crazy language; there are frequent surprises in all directions (slower than expected, faster than expected, behaves differently than expected).

If you have ideas how to improve object handling, I'd be glad to review a patch. Specifically, I'd be interested in how you envision making frozen properties "slightly faster" than regular properties. (But no hand-wavy "in an ideal world..." please, show me code.)