5 ms·

Some of the tests they link prove the opposite of what they say in the slides. Also, saying that eval is not evil is evil.

by fridek 15y ago

mikegirouard 15y ago
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.
dspillett 15y ago
> Some of the tests they link prove the opposite of what they say in the slides. The content can't be seen without signing in and it would appear that I've forgotten the password for my fake-details account, so I can't look at the code specifically. But I can say that it is not unexpected that the results one person gets can diverge significantly when someone else tries the same test. A lot of code rearrangements that are intended to speed up Javascript execution are optimised for a particular browser (or, if people are being more thorough, a particular subset of browsers). What is optimal for Firefox's engine is not necessarily so for Chrome's, and performance metrics can vary significantly between different versions of the same browser as changes are made to optimisations within the code interpreter/compiler over time. Heck, even exactly the same version of Firefox may behave differently performance-wise on Linux than Windows. You can never say that a given "trick" is an optimisation generally because there are many variables. Unless of course what you are actually doing is optimising your logic rather than rearranging it (i.e. changing from something that is akin to a linear search to something that has a logarithmic growth pattern) but that isn't optimising Javascript, it is optimising the algorithm you've implemented using the language. > Also, saying that eval is not evil is evil. There are very specific circumstances when eval() can be used with relative safety [i.e. when the only injection method is by direct code manipulation, and all client-side Javascript is susceptible to that with or without eval()]. Other than that I agree, and none of the cases where eval() is safe that spring to mind can't be implemented some other way (at least in modern browsers).
- ghusbands 15y ago
  While you're entirely correct that results can differ between browers, many of the links are to jsperf, which compensates for test-run variance and shows a comparative graph of all results; some of those graphs demonstrate the opposite of what the linking slides say. For an example, they link to http://jsperf.com/undefined-void0-perf http://jsperf.com/undefined-void0-perf to show that using void 0 instead of undefined is not a performance win. The data shows there's no browser in which void 0 is slower than undefined and several browsers in which is it faster, by as much as 50-60%.
  - jdd 15y ago
jdd 15y ago
You shouldn't simply look at the pretty bar charts to draw conclusions. Results that are millions of ops/sec vs. more-millions ops/sec aren't likely to be a performance issue in real world use. Eval, with-statements, arguments.callee, the Function constructor, and the like aren't "evil". They are just tools for you to use-wisely or abuse.

Some of the tests they link prove the opposite of what they say in the slides. Also, saying that eval is not evil is evil.

by fridek 15y ago

Some of the tests they link prove the opposite of what they say in the slides. Also, saying that eval is not evil is evil.

mikegirouard 15y ago

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.

dspillett 15y ago

> Some of the tests they link prove the opposite of what they say in the slides. The content can't be seen without signing in and it would appear that I've forgotten the password for my fake-details account, so I can't look at the code specifically. But I can say that it is not unexpected that the results one person gets can diverge significantly when someone else tries the same test. A lot of code rearrangements that are intended to speed up Javascript execution are optimised for a particular browser (or, if people are being more thorough, a particular subset of browsers). What is optimal for Firefox's engine is not necessarily so for Chrome's, and performance metrics can vary significantly between different versions of the same browser as changes are made to optimisations within the code interpreter/compiler over time. Heck, even exactly the same version of Firefox may behave differently performance-wise on Linux than Windows. You can never say that a given "trick" is an optimisation generally because there are many variables. Unless of course what you are actually doing is optimising your logic rather than rearranging it (i.e. changing from something that is akin to a linear search to something that has a logarithmic growth pattern) but that isn't optimising Javascript, it is optimising the algorithm you've implemented using the language. > Also, saying that eval is not evil is evil. There are very specific circumstances when eval() can be used with relative safety [i.e. when the only injection method is by direct code manipulation, and all client-side Javascript is susceptible to that with or without eval()]. Other than that I agree, and none of the cases where eval() is safe that spring to mind can't be implemented some other way (at least in modern browsers).

ghusbands 15y ago
While you're entirely correct that results can differ between browers, many of the links are to jsperf, which compensates for test-run variance and shows a comparative graph of all results; some of those graphs demonstrate the opposite of what the linking slides say. For an example, they link to http://jsperf.com/undefined-void0-perf http://jsperf.com/undefined-void0-perf to show that using void 0 instead of undefined is not a performance win. The data shows there's no browser in which void 0 is slower than undefined and several browsers in which is it faster, by as much as 50-60%.
- jdd 15y ago

jdd 15y ago

You shouldn't simply look at the pretty bar charts to draw conclusions. Results that are millions of ops/sec vs. more-millions ops/sec aren't likely to be a performance issue in real world use. Eval, with-statements, arguments.callee, the Function constructor, and the like aren't "evil". They are just tools for you to use-wisely or abuse.