Do comments slow down an interpreted language?
Solution 1
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.
Solution 2
Well, I wrote a short python program like this:
for i in range (1,1000000):
a = i*10
The idea is, do a simple calculation loads of times.
By timing that, it took 0.35±0.01 seconds to run.
I then rewrote it with the whole of the King James Bible inserted like this:
for i in range (1,1000000):
"""
The Old Testament of the King James Version of the Bible
The First Book of Moses: Called Genesis
1:1 In the beginning God created the heaven and the earth.
1:2 And the earth was without form, and void; and darkness was upon
the face of the deep. And the Spirit of God moved upon the face of the
waters.
1:3 And God said, Let there be light: and there was light.
...
...
...
...
Even so, come, Lord Jesus.
22:21 The grace of our Lord Jesus Christ be with you all. Amen.
"""
a = i*10
This time it took 0.4±0.05 seconds to run.
So the answer is yes. 4MB of comments in a loop make a measurable difference.
Solution 3
Comments are usually stripped out in or before the parsing stage, and parsing is very fast, so effectively comments will not slow down the initialization time.
Solution 4
The effect is negligable for everyday usage. It's easy to test, but if you consider a simple loop such as:
For N = 1 To 100000: Next
Your computer can process that (count to 100,000) quicker than you can blink. Ignoring a line of text that starts with a certain character will be more than 10,000 times faster.
Don't worry about it.
Solution 5
It depends on how the interpreter is implemented. Most reasonably modern interpreters do at least a bit of pre-processing on the source code before any actual execution, and that will include stripping out the comments so they make no difference from that point onward.
At one time, when memory was severely constrained (e.g., 64K total addressable memory, and cassette tapes for storage) you couldn't take things like that for granted. Back in the day of the Apple II, Commodore PET, TRS-80, etc., it was fairly routine for programmers to explicitly remove comments (and even white-space) to improve execution speed. This was also only one of many source code-level hacks routinely employed at the time1.
Of course, it also helped that those machines had CPUs that could only execute one instruction at a time, had clock speeds around 1 MHz, and had only 8-bit processor registers. Even a machine you'd now find only in a dumpster is so much faster than those were that it's not even funny...
1. For another example, in Applesoft you could gain or lose a little speed depending on how you numbered lines. If memory serves, the speed gain was when the target of a goto statement was a multiple of 16.
Mantas Vidutis
always on the move. operating a consultancy in SF: turbines.io
Updated on June 09, 2022Comments
-
Mantas Vidutis almost 2 years
I am asking this because I use Python, but it could apply to other interpreted languages as well (Ruby, PHP, JavaScript).
Am I slowing down the interpreter whenever I leave a comment in my code? According to my limited understanding of an interpreter, it reads program expressions in as strings and then converts those strings into code. It seems that every time it parses a comment, that is wasted time.
Is this the case? Is there some convention for comments in interpreted languages, or is the effect negligible?
-
Henrik Hansen about 14 yearsComments have to be stripped, so with big enough comments, they will slow down the program. But you got to have enormous comments (MBs? GBs?) before you can even measure it.
-
kennytm about 14 yearsHaving megabytes of comments means there are more than megabytes of code. Time for actual parsing and compiling would overwhelm the "little" comment stripping time.
-
Drew Delano about 14 years+1 for a scientific experiment and The Holy Bible in the same post. 8vD
-
AKX about 14 yearsI went ahead and tried this out. On my particular testing system parsing and executing about 10 megs of Python comments (and one assignment statement) takes 349 ms. The ratio of source bytes to time in this case seems to be fairly constant, at about 28,000 bytes per msec. The same script on Codepad is (as I imagined) slower: codepad.org/Ckevfqmq
-
Thomas Wouters about 14 yearsThat's not a comment. It's a string literal. Furthermore, if you look at the actual bytecode for your two blocks of code, you will see no difference. The string is parsed once, and not involved in the calculations at all. You should see the same slowdown if you place the string outside of the loop.
-
Drew Delano about 14 yearsThomas Wouters has a good point. Now go back and prefix each line of The Bible with '#'. ;v)
-
Drew Delano about 14 yearsCome to think of it, it wouldn't be hard to write a Python script to do just that.
-
janneb about 14 yearsWell, I'm sure one can construct a pathological example to the contrary. Oh look, see the answer by Rich Bradshaw. For all practical purposes, you're entirely right, of course.
-
M. Williams about 14 years+1, because I really liked the
gazillion
use in this context -
Mike Graham about 14 yearsIt's hard to imagine how high the comment:code ratio would have to be before this was detectable.
-
Seth Johnson about 14 years@Mike: possibly 1 gazillion:1 ?
-
M. Williams about 14 yearsNot quite sure about multiple gazillions, but I think you're thinking in the right way.
-
Rich Bradshaw about 14 yearsI've always used that notation for comments - it's a multiline comment.
-
yantrab about 14 yearsRich: it's not a comment, it's a string literal. The difference is that your multiline string is incorporated into the compiled bytecode, a comment is not.
-
Mike Graham about 14 yearsWhoa, you typed in the entire Bible? You must be really bored and really, really fast.
-
Mike Graham about 14 years@Ned, Yes and no. Obviously, it isn't a commen. However, this particular string literal will (in my CPython and I would bet money yours) be optimized out of the bytecode. The difference is the actual compile time.
-
Mike Graham about 14 years
s/will slow down the startup time/will slow down the startup time immeasurably
.s/in most cases comments don't slow down runtime/in all cases comments don't slow down runtime
-
visual_learner about 14 years@Mike Graham - Ever heard of Project Gutenberg? gutenberg.org/wiki/Main_Page
-
3Dave about 14 yearsI'm not sure I'd call this an "interpreted language" in the strictest sense of the word. Something like dynamically-compiled or JIT seems more appropriate.
-
3Dave about 14 years@Nick, I'd expect any non-naive interpreter to only parse the comments for the first pass through the loop. Have you tried this either with an unrolled loop, or by, say, pasting a couple of hundred lines of comments in the code?
-
3Dave about 14 years+1 to counter a stupid downvote, and props for actually experimenting, despite the flawed approach. TIAS (Try it and see) often provides better answers than abstract discussion.
-
Mike Graham about 14 years@David, the case this tests is not the one described by OP nor is it representative of anything like any code that people actually write.
-
wisty about 14 yearsTry changing the loop counter. It might be taking ~4 seconds just to parse the string literal.
-
Ian Bicking about 14 yearsI'm just noting that even compilation time only happens once and is then cached.
-
smci over 12 years@Rich, can you convert the string to a comment and post the new timing?
-
Yogesh Gandhi over 4 yearsWhat does "testing np.array(constants.LABELS)" actually mean? Do you see a difference in compiled .pyc files?
-
Code Pope over 4 years@LuperRouch with "testing np.array(constants.LABELS)" I mean to run the statement
np.array(constant.LABELS)
ten times and measuring the average execution time of the statement. I will clarify that in the text. -
Yogesh Gandhi over 4 yearsHow do you run this statement? Maybe you could push your test setup to github so we can see how exactly you run your test, as the difference you see is probably due to the fact that you don't reuse compiled .pyc files (as I said, comments do impact compilation time, but they should not impact execution time).