[Python-ideas] Disable all peephole optimizations

[Nick Coghlan]

On 8 Jun 2014 21:45, "Ned Batchelder" <ned at nedbatchelder.com> wrote:
>
> On 5/26/14 10:40 PM, Nick Coghlan wrote:
>>
>>
>> On 27 May 2014 10:28, "Ned Batchelder" <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> wrote:
>> >>>
>> >>> On Fri, May 23, 2014 at 10:49 AM, Guido van Rossum <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?

A PEP would help ensure the use cases are clearly documented and properly
covered by the chosen solution. It will also help cover all the incidental
details (like the impact on cache tags).

But either a patch or a PEP would get it moving - the main risk in going
direct to a patch is the potential for needing to rework the design.

Cheers,
Nick.

>
> --Ned.
>
>> Cheers,
>> Nick.
>>
>> >>
>> >>
>> >> --
>> >> --Guido van Rossum (python.org/~guido)
>> >>
>> >>
>> >> _______________________________________________
>> >> Python-ideas mailing list
>> >> 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
>> > 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/20140609/b43883b0/attachment-0001.html>