[Python-Dev] Thoughts on -O

Guido van Rossum guido@python.org
Mon, 28 Apr 2003 20:43:00 -0400


> Was doing some thinking in the shower this morning, and came up with
> some ideas for specifying optimisation. These are currently quite
> nebulous thoughts ...
> 
> We have the current situation:
> 
> -O only removes asserts

It may do some more, but not much more now that SET_LINENO is never
generated.

> -OO removes asserts and docstrings.
> 
> I think this is an ideal time to revisit the purpose of -O for 2.4 or later.

Hm, I would think we can wait until after 2.3 is released, lest we be
tempted to "push one more feature into 2.3".

> IMO the "vanilla" mode should be a "release" mode. Users should not
> have to use a command-line option to gain "release" optimisations
> such as asserts.

I strongly disagree, and I expect most Python users would.  I think
this idea of a default harks back to the time when computers were slow
and you would put on your special debugging hat only when you had a
problem you couldn't solve by thinking about it.  These days, often
you don't care about the small gain in speed that -O or even -OO
offers, because the program runs fast enough; but often you *do* care
about the extra checks that assert offers.  (I know I do.)

> I would propose that we have the following modes for python to work in.
> 
> 1. Release/Production mode (no command-line switch)
> 
>   - asserts are turned off
>   - well-tested/stable optimisations are included
>   - possibly additional things, such as not calling trace functions
> 
> 2. Optimised mode (-O)
> 
>   - more experimental optimisations are included i.e. those that may
>     have performance improvements in some cases, but penalties in
>     others, etc
> 
>   - may possibly split this up so individual optimisations can be
>     turned on and off as required - this would leave -O by itself as
>     a no-op
> 
> 3. Docstring elimination mode (-OO)
> 
>   - may be specified in addition to optimised mode - it does not
>     imply optimised mode
> 
> 4. Debug mode (-D?)
> 
>   - will be the slowest mode - no optimisations - cannot be called
>     with either -O or -OO
>   - turns on asserts
>   - turns on trace functions
> 
> I would see Debug mode being used by developers in unit tests, code
> coverage, etc.

If I'm right about how Python is used, most Python users are in debug
mode most of the time.  So this ought to be the default.

> .pyc and .pyo files would need to know which optimisations they were
> compiled with so that if they would be loaded again with the "wrong"
> optimisations they would be re-compiled.

That's what the difference between .pyc and .pyo was intended to
convey; IMO this was a mistake.

> Anyway, any thoughts, rebuttals, etc would be of interest. I'd like
> to get some discussion before I create a PEP.

I'm not convinced that we need anything, given the minimal effect of
most currently available optimizations.

--Guido van Rossum (home page: http://www.python.org/~guido/)