4 ms·
Nice! You've explained why this 'memory leak' could be by design - blame eval. In fact, Chrome GC-ing unreferenced variables could break eval if they didn't co
by j_s 13y ago
Nice! You've explained why this 'memory leak' could be by design - blame eval.
In fact, Chrome GC-ing unreferenced variables could break eval if they didn't cover that case.
- pcwalton 13y agoOnly direct `eval` though. As long as you don't see any calls to symbols named `eval`, you can implement this optimization. See http://stackoverflow.com/questions/8694300/how-eval-in-javascript-changes-the-calling-context http://stackoverflow.com/questions/8694300/how-eval-in-javas...
- deleted 13y ago[deleted]
- shardling 13y agoYeah, you could test this in the first example by replacing the string 'interval' with something like "alert(str.length)", and then redefining console.log=eval. e: nm, I missed pcwalton's point -- when you call eval indirectly it isn't accessing the same scope. So redefining console.log couldn't access local variables like str. (I don't think?)
- masklinn 13y agoCorrect. Not only is eval not a good idea in general, but it's a very weird beast in javascript. See http://perfectionkills.com/global-eval-what-are-the-options/ http://perfectionkills.com/global-eval-what-are-the-options/ for a very complete exposition of its weirdness.