3 ms·

Web Reflection: A Safer JS Environment

33 points by cleverjake 14y ago

kevingadd 14y ago
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 http://jsperf.com/freeze-vs-seal-vs-normal/3 [2] http://jsperf.com/variable-access-performance http://jsperf.com/variable-access-performance
- magicalist 14y ago
  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.
- lucian1900 14y ago
  Perhaps the terrible performance penalty should be fixed instead. Making something immutable shouldn't inherently make accessing it more expensive. Also, 88% isn't "terrible penalty". I can live with that, and I bet it'll improve anyway.
- luchs 14y ago
  Rather: should not be used in Chrome-only production code. The performance in Chrome doesn't seem too bad in comparison with other browsers.

33 points by cleverjake 14y ago

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 http://jsperf.com/freeze-vs-seal-vs-normal/3 [2] http://jsperf.com/variable-access-performance http://jsperf.com/variable-access-performance

magicalist 14y ago
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.
lucian1900 14y ago
Perhaps the terrible performance penalty should be fixed instead. Making something immutable shouldn't inherently make accessing it more expensive. Also, 88% isn't "terrible penalty". I can live with that, and I bet it'll improve anyway.
luchs 14y ago
Rather: should not be used in Chrome-only production code. The performance in Chrome doesn't seem too bad in comparison with other browsers.