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

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