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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4