1

I have seen that -OO is used to discard docstrings:

$ man python
   -O     Turn  on  basic  optimizations.  This changes the filename extension
          for compiled (bytecode) files from .pyc to .pyo.  Given twice,
          causes docstrings to be discarded.

   -OO    Discard docstrings in addition to the -O optimizations.

Why should one ever want to discard docstrings? What is the advantage? Does -OO give a speed advantage for some code? (Why?)

Martin Thoma
  • 124,992
  • 159
  • 614
  • 958
  • Related: [What is the use of Python's basic optimizations mode? (`python -O`)](http://stackoverflow.com/q/1693088/562769) – Martin Thoma Aug 01 '14 at 22:34
  • I'm no expert, but stripping useless comments _should_ make parsing faster. – espenoh Aug 01 '14 at 22:38
  • 2
    @Kleevah: How should it make parsing faster? You have to find the end of the docstring (which is, by the way, not a useless comment but something that can actually be used in code). So you have to parse it anyway. – Martin Thoma Aug 01 '14 at 22:40
  • It will make the compiled bytecode files smaller. – Roland Smith Aug 01 '14 at 22:46
  • @RolandSmith More interesting is whether it'll make them smaller by any worthwhile margin, especially when you also compress the files. –  Aug 01 '14 at 22:49
  • @moose I assume it gets stripped when generating the bytecode, so that it gets smaller and that the interpreter don't have to do any checks related to comments when running from the .pyo. I doubt it's a very effective optimization on modern machines, but it should have _some_ effect. – espenoh Aug 01 '14 at 22:51
  • 1
    Honestly, the only usefulness I see for stripping docstrings on a "normal" PC is to make reverse engineering of distributed .pyo a little harder; although Python bytecode is relatively straightforward to decompile, leaving in also the documentation seems a bit too much. – Matteo Italia Aug 01 '14 at 22:57
  • @delnan On a small module (about 9 kiB `pyc` file) the `pyo` was approximately 10% smaller. That will make a difference IMO. Bytecode files are not compressed. The internal format is undocumented, but compressing `pyo` files with e.g. `gzip` can make them >50% smaller. That would not work if the data was already compressed. – Roland Smith Aug 01 '14 at 22:59
  • @RolandSmith Bytecode files are indeed not compressed, I was talking about compressing them with some external tool. Which is what you'd do if you gave a damn about a couple of KiB of disk space, hence my question. –  Aug 01 '14 at 23:02
  • @delnan The big question about compression is if the delay in decompression would outweigh the gain of reading a smaller file? It would probably depend on a lot of variables. But my gut feeling is that I don't think compression would be a net gain. – Roland Smith Aug 01 '14 at 23:08
  • @RolandSmith My gut feeling is that if a kilobyte of disk space matters, you're probably in a situation where you'd gladly cut your disk use in half at the cost of slightly slower launch. –  Aug 01 '14 at 23:13

1 Answers1

3

There is no speed advantage, aside from the time taken to read the docstrings from the bytecode file into memory (a tiny fraction of the already tiny and one-off startup time, unless your docstrings are pointlessly huge).

However, removing docstrings makes the bytecode smaller and reduces the memory footprint of the running program, by the cumulative size of all docstrings. On a desktop computer this is usually not noticeable. Allegedly this saves a small but significant fraction of disk space and RAM for some embedded (as in embedded system, not a Python interpreter included in other software) uses of Python.

  • Is Python used in embedded systems? I always thought that you would rather use C on embedded devices for exactly this reason: You need less disk space, less memory and probably also less computing power. – Martin Thoma Aug 01 '14 at 23:54
  • 1
    Depending on your definition of "embedded system", things like the Raspberry Pi and the Beaglebone Black run Python just fine. – Roland Smith Aug 02 '14 at 00:08