[Python-ideas] Disable all peephole optimizations
Haoyi Li
haoyi.sg at gmail.com
Tue May 27 04:45:21 CEST 2014
> - bytecode files are neither read nor written
Yay! That would be amazing...
On Mon, May 26, 2014 at 7:40 PM, Nick Coghlan <ncoghlan at gmail.com> 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).
>
> 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/
>
> _______________________________________________
> 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/20140526/8f2a2375/attachment-0001.html>
More information about the Python-ideas
mailing list