3 ms·

My eval tests said the same. I'm not sure if thats indicative of a host-specific performance problem or if it is with eval itself. Perhaps the problem I have i

My eval tests said the same. I'm not sure if thats indicative of a host-specific performance problem or if it is with eval itself. Perhaps the problem I have is with this statement: > "Eval is evil", or in other words, Eval is too slow and quirky to be considered useful. That's misleading. While performance of eval is perhaps getting better, eval is still evil for a number of reasons that aren't related to performance at all.

tikhonj 15y ago
The same is true with undefined. You should use void 0 rather than undefined because undefined is just a normal variable which happens to be undefined unless somebody defines it, while void 0 is always going to be undefined.
- jdd 15y ago
  There is absolutely no need to use `void 0` you can simply use `typeof` or create a local `undefined` var. Many libs do this in their IIFE `(function(undefined) { /* your code */ }());`. The point was there isn't a real world performance concern to justify using one over the other.
fridek 15y ago
Eval breaks both JIT[1] and garbage collection [2] (unless used very carefully). It also affects Google Closure Compiler [3]. What is even better - it won't ever be fixed, at least not in the terms of performance. [1] http://echo.nextapp.com/site/node/6097 http://echo.nextapp.com/site/node/6097 [2] http://stackoverflow.com/questions/5368048/how-are-closures-and-scopes-represented-at-run-time-in-javascript http://stackoverflow.com/questions/5368048/how-are-closures-... [3] http://groups.google.com/group/closure-compiler-discuss/browse_thread/thread/e01e087142784940/4e4dd45ee97fc1c8 http://groups.google.com/group/closure-compiler-discuss/brow...
- jdd 15y ago
  Garbage collection was brought up during the Q/A and I would dig a jsPerf revision to explore that. One of the tests included in the slides was to see if simply using `eval` in a method would disable optimizations: http://jsperf.com/eval-kills http://jsperf.com/eval-kills Chris (@robodynamo) included the slide about `eval` because he found it performant/useful in his day job. Eval has it's uses, for example it's used in json2.js as part of the JSON fallback.

tikhonj 15y ago

The same is true with undefined. You should use void 0 rather than undefined because undefined is just a normal variable which happens to be undefined unless somebody defines it, while void 0 is always going to be undefined.

jdd 15y ago
There is absolutely no need to use `void 0` you can simply use `typeof` or create a local `undefined` var. Many libs do this in their IIFE `(function(undefined) { /* your code */ }());`. The point was there isn't a real world performance concern to justify using one over the other.

fridek 15y ago

Eval breaks both JIT[1] and garbage collection [2] (unless used very carefully). It also affects Google Closure Compiler [3]. What is even better - it won't ever be fixed, at least not in the terms of performance. [1] http://echo.nextapp.com/site/node/6097 http://echo.nextapp.com/site/node/6097 [2] http://stackoverflow.com/questions/5368048/how-are-closures-and-scopes-represented-at-run-time-in-javascript http://stackoverflow.com/questions/5368048/how-are-closures-... [3] http://groups.google.com/group/closure-compiler-discuss/browse_thread/thread/e01e087142784940/4e4dd45ee97fc1c8 http://groups.google.com/group/closure-compiler-discuss/brow...

jdd 15y ago
Garbage collection was brought up during the Q/A and I would dig a jsPerf revision to explore that. One of the tests included in the slides was to see if simply using `eval` in a method would disable optimizations: http://jsperf.com/eval-kills http://jsperf.com/eval-kills Chris (@robodynamo) included the slide about `eval` because he found it performant/useful in his day job. Eval has it's uses, for example it's used in json2.js as part of the JSON fallback.