[Python-Dev] Re: [Python-checkins] python/dist/src/Python compile.c, 2.319, 2.320

Brett C. bac at OCF.Berkeley.EDU
Thu Aug 19 05:40:09 CEST 2004


Raymond Hettinger wrote:
>>>Move the bytecode optimizer upstream so that its results are saved
>>>in pyc files and not re-optimized upon import.  Saves a bit of
>>>startup time while still remaining decoupled from the rest of the
>>>compiler.
>>
>>Hm, shouldn't the bytecode optimizer only be used when -O is used, and
>>hence pyo files are being written?
> 
> 
> Why?  That would throw away most of the benefits to most of the users
> and gain nothing in return.  The peepholer was in place in for Py2.3 and
> only benefits were seen.  I would save the -O option for something where
> there is a trade-off (loss of docstrings, excessive compilation time,
> possibly risky optimizations, or somesuch).  Here, the peepholer is
> superfast and costs almost nothing.
> 

Seems we need a definition of philosophy for Python.  Is a compiler 
optimization *anything* that changes the opcode initially emitted by the 
compiler, or only opcodes that can have some adverse affect, such as 
larger files or longer compile times.

If you take a strict reading of the first philosophy the optimization of 
changing a constant having the unary negative op applied to it changed 
into a negative constant (that bit me in the ass hard for my thesis 
since it changes the CST directly; bet my next bug is something 
similar).  That does change what is going to be emitted very far 
upstream.  And if I remember from the last time I looked at the peephole 
optimizer it just changes some jump values to absolute and a few other 
minor things.

Personally, I go with the latter philosophy.  -O still has its place 
since it removes asserts.  But if an optimization doesn't change the 
semantics (such as removing asserts), doesn't take a lot of time (such 
as a bunch of walks along the opcodes), or increase space (unrolling 
loops), then I don't see any harm.  Just think of it as what the 
compiler would have emitted could it be inlined within its innards easily.

-Brett


More information about the Python-Dev mailing list