[Python-ideas] Disable all peephole optimizations

[Ned Batchelder]

On 5/26/14 10:40 PM, Nick Coghlan wrote:
>
>
> On 27 May 2014 10:28, "Ned Batchelder" <ned at nedbatchelder.com 
> <mailto:ned at nedbatchelder.com>> wrote:
> >
> > On 5/23/14 1:22 PM, Guido van Rossum wrote:
> >>
> >> On Fri, May 23, 2014 at 10:17 AM, Eric Snow 
> <ericsnowcurrently at gmail.com <mailto:ericsnowcurrently at gmail.com>> wrote:
> >>>
> >>> On Fri, May 23, 2014 at 10:49 AM, Guido van Rossum 
> <guido at python.org <mailto:guido at python.org>> wrote:
>
> >>>
> >>> Would it be a problem if .pyc files weren't generated or used (a la -B
> >>> or PYTHONDONTWRITEBYTECODE) when you ran coverage?
> >>
> >>
> >> In first approximation that would probably be okay, although it 
> would make coverage even slower. I was envisioning something where it 
> would still use, but not write, pyc files for the stdlib or 
> site-packages, because the code in whose coverage I am interested is 
> puny compared to the stdlib code it imports.
> >
> >
> > I was concerned about losing any time in test suites that are 
> already considered too slow.  But I tried to do some controlled 
> measurements of these scenarios, and found the worst case (no .pyc 
> available, and none written) was only 2.8% slower than full .pyc files 
> available.  When I tried to measure stdlib .pyc's available, and no 
> .pyc's for my code, the results were actually very slightly faster 
> than the typical case.  I think this points to the difficult in 
> controlling all the variables!
> >
> > In any case, it seems that the penalty for avoiding the .pyc files 
> is not burdensome.
>
> Along these lines, how about making the environment variable something 
> like "PYTHONANALYSINGSOURCE" with the effects:
>
> - bytecode files are neither read nor written
> - all bytecode and AST optimisations are disabled
>
> A use case oriented flag like that lets us tweak the definition as 
> needed in the future, unlike an option that is specific to turning off 
> the CPython peephole optimiser (e.g. we don't have an AST optimiser 
> yet, but turning it off would still be covered by an "analysing 
> source" flag).
>

My inclination would still be to provide separate controls like 
"DISABLE_OPTIMIZATIONS" and "DISABLE_BYTECODE", these are power tools in 
any case.  What is the process from this point forward?  A patch? A PEP?

--Ned.
>
> Cheers,
> Nick.
>
> >>
> >>
> >> --
> >> --Guido van Rossum (python.org/~guido <http://python.org/%7Eguido>)
> >>
> >>
> >> _______________________________________________
> >> Python-ideas mailing list
> >> Python-ideas at python.org <mailto:Python-ideas at python.org>
> >> https://mail.python.org/mailman/listinfo/python-ideas
> >> Code of Conduct: http://python.org/psf/codeofconduct/
> >
> >
> >
> > _______________________________________________
> > Python-ideas mailing list
> > Python-ideas at python.org <mailto:Python-ideas at python.org>
> > https://mail.python.org/mailman/listinfo/python-ideas
> > Code of Conduct: http://python.org/psf/codeofconduct/
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20140608/84bd3141/attachment.html>