10

Possible Duplicate:
Do comments slow down an interpreted language?

Will there be noticeable performance degradation in the execution of a large .py file if more than 75% of the lines of code are properly commented?

Community
  • 1
  • 1
thegrandchavez
  • 1,730
  • 2
  • 12
  • 20
  • 3
    No, but if you have comments on 75% of your code, you may benefit from not commenting so much and rather writing readable code. –  May 07 '12 at 18:35

1 Answers1

20

No

When you run python, the first step is to convert to bytecode, which is what those .pyc files are. Comments are removed from these, so it won't matter*.

If you run with the -O or -OO option, python will produce "optimized" pyo files, which are negligibly faster, if faster at all. The main difference is that:

  • with -O assertion are removed,
  • with the -OO option, the __doc__ strings are stripped out. Given that those are sometimes needed, running with -OO isn't recommended.

* it's been pointed out below that .pyc files are only saved for modules. Thus the top-level executable must be recompiled every time it's run. This step could slow down a massive python executable. In practice, most of the code should reside in modules, making this a non-issue.

Shep
  • 7,990
  • 8
  • 49
  • 71
  • 4
    ...so it could impact your *startup* time, but not your long term execution time. In particular, if everything is precompiled into `.pyc` files, this is a *one time* cost, not a per-run cost. – larsks May 07 '12 at 17:51
  • I doubt it will impact the startup time noticeably, since Python simply ignores anything between a # and a newline. Also, the .pyc files are preserved between runs if the .py file is not modified, so any effect is only for the first time the program is run. – Andrew Gorcester May 07 '12 at 17:52
  • -1, since only imported modules are compiled to .pyc; executed scripts are not. – Wooble May 07 '12 at 17:53
  • 1
    @Wooble, good point, but I've never noticed the effect. The only scenarios I can think of where this would matter are when you're running a _very_ long strip or where you're making repeated calls to a python executable from outside python. In practice I've never run into either. – Shep May 07 '12 at 17:58
  • 7
    @Wooble if you're following best-practices, your scripts are only thin wrappers around modules; setuptools and kin will even generate these wrappers for you automatically. – Charles Duffy May 07 '12 at 18:00
  • 1
    @CharlesDuffy: maybe so, but OP speaks of "execution of a large .py file". Of course the comments will only affect startup time, but it will be every time the large script is run, because a .pyc file won't be created. The "No" part is correctish, but the explanation is misleading. – Wooble May 07 '12 at 18:03
  • 1
    Even if you have a large, monolithic `.py` file invoked directly from the command line, it's trivial to write a "wrapper" for it that simply imports the big script. Then the big script gets compiled to a `.pyc` and only the one-line wrapper is parsed each time it's run. – kindall May 07 '12 at 18:28
  • 1
    More nitpicking: `-O` removes assertions and sets `__debug__ = False`, but it does not remove docstrings, only `-OO` does that. Running with `-O` is thus only harmful when you're debugging (or misusing assertions, which some codebases do). –  May 07 '12 at 18:37
  • @delnan thanks for pointing this out. I've added to my answer. – Shep May 07 '12 at 18:43