[Python-ideas] Standard (portable) bytecode "assembly" format

Brett Cannon brett at python.org
Fri Feb 26 11:50:21 EST 2016


On Fri, 26 Feb 2016 at 02:27 Victor Stinner <victor.stinner at gmail.com>
wrote:

> 2016-02-26 6:27 GMT+01:00 Andrew Barnert via Python-ideas
> <python-ideas at python.org>:
> [SNIP]
>
> > And PyCode_Assemble is the only new C API function needed.
>
> I don't understand why do you care so much of having a C API. What do
> you want to do?
>
> The only need for CPython is to have the most simple peephole
> optimizer, basically only optimize jumps. An AST optimizer can do
> everything else. I would like to experiment such peephole optimizer
> implemented in pure Python.
>
> I'm not sure that writing it in pure Python will kill performances.
> The cost of import matters, but only in few use cases. In general,
> applications run longer than 1 second and so the cost of import is
> negligible. Moreover, .py are only compiled once to .pyc. If .pyc are
> precompiled, the speed of the optimizer doesn't matter :-)
>

So one thing to point out (that I know Raymond Hettinger would ;) ), is
that Python scripts passed by file path on the command-line are not written
out to a .pyc file, and so at least the initial entry point will still have
to pay for any optimizer overhead no matter what. And if you write your
entire app in a single file for ease-of-shipment then you will pay the
penalty 100% of the time and not just for some small __main__ module. Now
if the balance between overhead vs. the optimization benefit for everyone
else balances out then it's worth the cost, but the question is what
exactly that cost works out to be.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160226/7fb51ee3/attachment.html>


More information about the Python-ideas mailing list