Commenting Interpreted Code and Performance

Commenting interpreted code and performance

For PHP, it makes no difference. Your PHP code isn't sent out to the browser.

For JavaScript, it is recommended that you minify your code. This reduces its size by changing variable names, removing white space, and removing all comments as well. There are several online tools for doing this, and it is often available in your IDE.

Whatever you do, leave your code commented where you work on it. Don't remove comments from PHP, and don't minify your JS by hand.

Do comments slow down an interpreted language?

For the case of Python, source files are compiled before being executed (the .pyc files), and the comments are stripped in the process. So comments could slow down the compilation time if you have gazillions of them, but they won't impact the execution time.

Do comments slow down a compiled language?

When you compile the program, the compiler actually does:

• Lexical Analysis (tokenization)
• Syntax Analysis (parsing)
• Semantic Analysis (language rules checked)
• [Intermediate] Code Generation
• Code Optimization (optional)

As for comments they should be extracted as tokens on Lexical Analysis stage and dropped out on Syntax Analysis (parsing) stage. So you can slow down the compiler, but not the code generated.

Many interpreted languages often do first two or three stages and only then execute, so comments don't necessarily slow down even interpreted languages.

Will PHP be slower if we add too many comments in code files?

Yes, but it's minimal, and this can (and should) be addressed entirely by using APC or another opcode cache. As a bonus, APC will speed everything else up as well.

If your site is slow, comments are not the reason.

Do comments affect performance?

Am I correct to say that JavaScript code isn't compiled, not even JIT?

No. Although JavaScript is traditionally an "interpreted" language (although it needn't necessarily be), most JavaScript engines compile it on-the-fly whenever necessary. V8 (the engine in Chrome and NodeJS) used to compile immediately and quickly, then go back and aggressively optimize any code that was used a lot (the old FullCodegen+TurboFan stack); a while back having done lots of real-world measurement, they switched to initially parsing to byteocde and interpreting, and then compiling if code is reused much at all (the new Ignition+TurboFan stack), gaining a significant memory savings by not compiling run-once setup code. Even engines that are less aggressive almost certainly at least parse the text into some form of bytecode, discarding comments early.

Remember that "interpreted" vs. "compiled" is usually more of an environmental thing than a language thing; there are C interpreters, and there are JavaScript compilers. Languages tend to be closely associated with environments (like how JavaScript tends to be associated with the web browser environment, even though it's always been used more widely than that, even back in 1995), but even then (as we've seen), there can be variation.

If so, does that mean that comments have an affect on performance...

A very, very, very minimal one, on the initial parsing stage. But comments are very easy to scan past, nothing to worry about.

If you're really worried about it, though, you can minify your script with tools like jsmin or the Closure Compiler (even with just simple optimizations). The former will just strip comments and unnecessary whitespace, stuff like that (still pretty effective); the latter does that and actually understands the code and does some inlining and such. So you can comment freely, and then use those tools to ensure that whatever minuscule impact those comments may have when the script is first loaded is bypassed by using minifying tools.

Of course, the thing about JavaScript performance is that it's hard to predict reliably cross-engine, because the engines vary so much. So experiments can be fun:

• Here's an experiment which (in theory) reparses/recreates the function every time
• Here's one that just parses/creates the function once and reuses it

Result? My take is that there's no discernable difference within the measurement error of the test.

Does comments makes the run program slow?

No, not in Java. Comments are removed when you compile your code.

Further explaining, it depends on the type of programming language you are using. For compiled programs, only the executable files are used by the computer during running the program instead of the source files. For example in java, .class files files does not have any traces of comments to make the program slow.

In case of interpreted languages like PHP, interpreter has to know that its a comment on every line starting with //. So it might take a faction of seconds (usually negligible) more time to execute.

But in case web languages like HTML and JavaScript, the comments are actually fetched to the client. When you click on view source of a webpage, you can see the actual HTML and JavaScript comments. This ofcourse will have to be loaded to the machine and will take considerable amount of time. Therefore, we care about minifying HTML, CSS and JS in the production environment.

So to sum up, it depends on programming languages whether the comments make a program slower.

Hope it was helpful.

Do comments make the code run slower?

Commenting will not affect the script execution time in normal case. But the number of lines you write in your code affect the parser to read and buffer it considerably. If you can execute certain things in 20 lines, you try to write the same thing in 1000 lines, the performance might be affecting if its part of an application which executes sequentially. Even if few lines or lot of lines the dependencies are important. If you are using a library which is heavily depending on some applications, obviously the loading time, parsing time and compile and execution time etc will increase. In any case the commenting will not affect considerably, but a few microseconds will not cost you much. So go ahead and comment your code and make it readable by co-developers.

Do comments get translated to machine code? C++

Comments are normally stripped out during preprocessing, so the compiler itself never sees them at all.

They can (and normally do) slow compilation a little though--the preprocessor has to read through the entire comment to find its end (so subsequent code will be passed through to the compiler. Unless you include truly gargantuan comments (e.g., megabytes) the difference probably won't be very noticeable though.

Although I've never seen (or heard of) a C or C++ compiler that did it, there have been compilers (e.g., for Pascal) that used specially formatted comments to pass directives to the compiler. For example, Turbo Pascal allowed (and its successor probably still allows) the user to turn range checking on and off using a compiler directive in a comment. In this case, the comment didn't (at least in the cases of which I'm aware) generate any machine code itself, but it could and did affect the machine code that was generated for the code outside the comment.

Do comments affect Perl performance?

Perl is a just-in-time compiled language, so comments and POD have no effect on run-time performance.

Comments and POD have a minuscule effect on compile-time, but they're so easy and fast for Perl to parse it's almost impossible to measure the performance hit. You can see this for yourself by using the -c flag to just compile.

On my Macbook, a Perl program with 2 statements and 1000 lines of 70 character comments takes the same time to compile as one with 1000 lines of empty comments as one with just 2 print statements. Be sure to run each benchmark twice to allow your OS to cache the file, otherwise what you're benchmarking is the time to read the file from the disk.

If startup time is a problem for you, it's not because of comments and POD.

---

Related Topics