[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