This is a good thing to raise awareness of, but the solution is poor advice.<p>Asking developers to remember the "gotcha" of 600 characters is not really viable. Instead, if this is important to you, consider the addition of minification or comment stripping to your production deployment process. Minification will also make the variable names and syntax use shorter, saving you further precious characters.<p>Learn the problem, but automate the solution.
This is a microbenchmark. It's a tight loop that calls the function 500 million times. The function itself just adds two numbers. It's pretty close to the best possible improvement for inlining a function. If that's what your program does, and it's a big part of what your program does, then inlining it may be a big performance win. Even then, addressing this may not be a worthwhile tradeoff. Even then, as others have pointed out, you could use a minimizer.<p>If your program is not CPU-bound, or if it doesn't have a function that's called millions of times in a tight loop, or if that doesn't make up the majority of time spent on CPU, or if that function does more than execute a couple of instructions, then the performance difference will likely be enormously less.
If you're wondering why comments are a factor at all, and aren't just discarded by the lexer, remember that comments in JS are preserved and available to things like `Function.prototype.toString()`. I've seen this used to do evil multiline string support a few times. Slap the multiline string or template into a comment inside a function and then have another function that toStrings it and strips the boilerplate.<p>This sounds like a horrifying hack but it's also pretty similar to how Angular's shorthand DI works.
The bug has been marked as WontFix by the V8 team: <a href="https://code.google.com/p/v8/issues/detail?id=3354" rel="nofollow">https://code.google.com/p/v8/issues/detail?id=3354</a>. It looks like they are considering fixing it for TurboFan and not for Crankshaft, but I'm not sure what that means. Does that only apply to asm.js code?
Wow, the v8 optimizer can sometimes be a pretty blunt instrument. Shouldn't it look at the size of the inlined function after it compiles it to some intermediate state that erases things like comments and names?
One comment mentions a quite significant speedup when switching the variable initialization step of the for loop from let to var. As excepted, you'll also get this if you keep the "let" keyword, but move it outside of the loop.<p>What kind of optimization step is prevented here?
Posted that yesterday, didn't get much traction.<p>Whenever I begin to convince myself that JS and Node are actually fine languages / environments to code on, some weird edge case like this pops up.<p>Not entirely sure if it's just its popularity, which is bound to expose its rough corners, or if it's fundamentally bad designed (written in 10 days in the late 90's, etc)
This cheerfully reminded me of the thing in MRI Ruby of (relatively recent) yesteryear where strings longer than 23 characters were twice as slow, qv. <a href="http://patshaughnessy.net/2012/1/4/never-create-ruby-strings-longer-than-23-characters" rel="nofollow">http://patshaughnessy.net/2012/1/4/never-create-ruby-strings...</a>
Good to know as a "gotcha" but typically when you get to an optimization like this you should have covered all other bigger optimizations like minification, ... that this won't actually return big yields.
Who need this? Prople writing really really performant code like parsers. Who write parsers? 1% of ppl? Sad this get so much exposure. Stop losing time with micro optimization, this is a bug that's it.
So, is this is a point in favor of <i>not</i> commenting your Javascript code or using inline docs?<p>Historically, I preferred to use inline JsDoc style comments as the source of documentation for my public APIs. Recently though, I decided that I didn't like them and that I wanted something better. I was hoping to find some tool that parses my JS to AST, figures out what was being exported (e.g. what was public) and writes a JSON document that I could diff over time, to figure out what was documented and what wasn't (in my external docs). So far, I have found this project called `doctor` which sounded close to what I'm looking for, but it still relies on comments ~ <a href="https://github.com/jdeal/doctor" rel="nofollow">https://github.com/jdeal/doctor</a> ~ So, I might have to write it myself using something like Esprima to get the AST...