On Fri, Mar 6, 2015, at 13:34, Brett Cannon wrote: > On Fri, Mar 6, 2015 at 1:27 PM Neil Girdhar <mistersh...@gmail.com> > wrote: > > > On Fri, Mar 6, 2015 at 1:11 PM, Brett Cannon <br...@python.org> wrote: > > > >> > >> > >> On Fri, Mar 6, 2015 at 1:03 PM Mark Shannon <m...@hotpy.org> wrote: > >> > >>> > >>> On 06/03/15 16:34, Brett Cannon wrote: > >>> > Over on the import-sig I proposed eliminating the concept of .pyo files > >>> > since they only signify that /some/ optimization took place, not > >>> > /what/ optimizations took place. Everyone on the SIG was positive with > >>> > the idea so I wrote a PEP, got positive feedback from the SIG again, > >>> and > >>> > so now I present to you PEP 488 for discussion. > >>> > > >>> [snip] > >>> > >>> Historically -O and -OO have been the antithesis of optimisation, they > >>> change the behaviour of the program with no noticeable effect on > >>> performance. > >>> If a change is to be made, why not just drop .pyo files and be done with > >>> it? > >>> > >> > >> I disagree with your premise that .pyo files don't have a noticeable > >> effect on performance. If you don't use asserts a lot then there is no > >> effect, but if you use them heavily or have them perform expensive > >> calculations then there is an impact. And the dropping of docstrings does > >> have an impact on memory usage when you use Python at scale. > >> > >> You're also assuming that we will never develop an AST optimizer that > >> will go beyond what the peepholer can do based on raw bytecode, or > >> something that involves a bit of calculation and thus something you > >> wouldn't want to do at startup. > >> > > > > I don't want to speak for him, but you're going to get the best results > > optimizing ASTs at runtime, which is what I thought he was suggesting. > > Trying to optimize Python at compile time is setting your sights really > > low. You have so little information then. > > > > OK, I don't want to derail the discussion of the PEP into one over how > best > to optimize CPython's performance relative to bytecode vs. runtime like > PyPy. The point is that we have -O and -OO and people do have uses for > those flags. People can also do custom optimizations thanks to the > flexibility of loaders.
I think it would be preferable deprecate -O and -OO and replace them with flags like --no-docstrings or --no-asserts. Ideally, "optimization" levels shouldn't change program semantics. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com