Does removing comments from JavaScript code improve performance?
I realize that this is not great programing practice as comments form an intrinsic part of development. I am just interested to know if they do in fact add some overhead during compilation.
Whether your compiling or interpreting your JavaScript, the compiler/interpreter needs to look at the line, decide it's a comment, and move on (or look at a region of the line). For web applications, the comment lines also need to be downloaded.
So yes, there is some overhead.
However, I doubt you could find a real-world scenario where that difference matters.
If you are compiling your code, the overhead is only during the compile run, not during subsequent execution.
Removing comments will make the Javascript file smaller and easier to download.
Other than that, it will not affect noticably performance at all.
If you're concerned about bandwidth and want to make the file smaller, the best thing to do is to the file through JSMin or a similar tool before deploying it to your production web site. (Make SURE to keep the original file, though).
As of September 24, 2016, the below answer is no longer accurate.
The source-length heuristic was removed in this commit: https://github.com/v8/v8/commit/0702ea3000df8235c8bfcf1e99a948ba38964ee3#diff-64e6fce9a2a9948942eb00c7c1cb75f2
The surprising answer is possibly!
As Eric noted, there is overhead in terms of downloading and parsing, but this is likely to be so small as to be unnoticeable in most cases.
However, JavaScript performance is a treacherous beast to tame, and there is at least one other way that comments can affect performance.
Modern (as of 2016) JavaScript engines such as V8 do a lot of fairly heavy work to ensure high performance. One of the things that these engines do is called JIT - "Just In Time" compilation. JIT compilation includes a number of complicated and occasionally unintuitive steps, one of which is inlining appropriate small functions into the call site.
Inlining means that given code like this:
function doIt(a, b) {
return (a + b) * 2;
}
function loop() {
var x = 1, y = 1;
var i;
for(i = 0; i < 100; ++i) {
x = doIt(x, y);
}
}
the compiler will do the equivalent of converting to this code:
function loop() {
var x = 1, y = 1;
var i;
for(i = 0; i < 100; ++i) {
// the doIt call is now gone, replaced with inlined code
x = (x + y) * 2;
}
}
The JIT compiler is able to determine that it's fine to replace the call to doIt with the body of the function. This can unlock big performance wins, as it removes the performance overhead of function calls completely.
However, how does the JavaScript engine choose which functions are suitable for inlining? There are a number of criteria, and one of them is the size of the function. Ideally, this would be the size of the compiled function, but V8's optimizer uses the length of the human-readable code in the function, including comments.
So, if you put too many comments in a function, it can potentially push it past V8's arbitrary inline function length threshold, and suddenly you are paying function call overhead again.
Please take a look at Julien Crouzet's neat post for more details:
Note that Julien talks about Crankshaft; V8 has since introduced TurboFan but the source length criteria remains.
The full list of criteria is in the (remarkably readable) TurboFan source code here, with the source length criteria highlighted:
Performance lag while browser interprets code? No significant difference. But it does add to bytesize which makes is longer to download.
But that's no reason to omit comments. Keep your development codebase commented. Use javascript compressors prior to release.
Also, during the release, try to bunch up your entire javascript codebase for a page inside a single file so as to minimize HTTP requests. HTTP requests bear a significant performance penalty.
It would make no noticeable difference to the execution of the JavaScript.
What it does make a difference to is the size of the JavaScript files being downloaded to client browsers. If you have lots of comments, it can significantly increase the size of the JavaScript files. This can be even more so with whitespace characters used for layout.
The usual approach is to "minify" .js files before deployment to remove comments and whitespace characters. Minifiers can also rename variables to shorter names to save extra space. They usually make the original JavaScript unreadable to the human eye though, so it is best to make sure you keep a copy of the un-minified file for development.
Another issue is that comments of the sort "This code is crap but we must meed the deadline" may not look as good in customer's browser.
I'm not sure about runtime speed, but removing comments will decrease download size, which is just as important.
You should always have comments in the code you work on, and use a minifier to strip them out for deployment - YUI Compressor is a good one.
