
Web Reflection: A Safer JS Environment - cleverjake
http://webreflection.blogspot.com/2012/08/a-safer-js-environment.html
======
kevingadd
Object.freeze and Object.seal should absolutely not be used in production code
unless you have no choice. They incur a tremendous performance penalty in V8
[1] and aren't great in other engines either. Combining them with the window
object (aka this in global scope) isn't going to be great either since that
thing also comes with a terrible performance penalty [2].

[1] <http://jsperf.com/freeze-vs-seal-vs-normal/3>

[2] <http://jsperf.com/variable-access-performance>

~~~
magicalist
Well, not every app is a game and needs things like superfast property access
at all times. A typical app needs to be responsive, but "decently fast"
property access can fall well within what's needed for "responsive", plus you
get all these new guarantees about unmodified state. The lower numbers in the
first benchmark are still fairly fast, it's just that cached property access
is so much faster (the test itself is also approaching about as microbenchmark
as you can get, so we shouldn't generalize with the results too much).

Really, Object.freeze, seal, etc are not widely used yet, and so aren't found
much in the popular benchmarks, and so haven't received much attention from
the Javascript engine writers. That will change if they start to become more
popular. My understanding is that v8, for instance, just doesn't touch those
after the initial code generation, so you don't get the optimizing compiler at
all right now. That will change very quickly if the next version of the Kraken
suite has a bunch of tests with sealed and frozen objects.

