This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gvanrossum
Recipients brett.cannon, francismb, gvanrossum, ncoghlan, vstinner, yselivanov
Date 2016-05-02.21:13:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
OK, I get it. I think it would be really helpful if issue 26110 was updated, reviewed and committed -- it sound like a good idea on its own, and it needs some burn-in time due to the introduction of two new opcodes. (That's especially important since there's also a patch introducing wordcode, i.e. issue 26647 and undoubtedly the two patches will conflict.) It also needs to show benchmark results on its own (but I think you've got that).

I am also happy to see the LOAD_GLOBAL optimization, and it alone may be sufficient to save PEP 509 (though I would recommend editing the text of the PEP dramatically to focus on a brief but crisp description of the change itself and the use that LOAD_GLOBAL would make of it and the microbench results; it currently is a pain to read the whole thing).

I have to read up on what you're doing to LOAD_ATTR/LOAD_METHOD. In the mean time I wonder how that would fare in a world where most attr lookups are in namedtuples.

As a general recommendation I would actually prefer more separate patches (even though it's harder on you), just with very clearly stated relationships between them.

A question about the strategy of only optimizing code objects that are called a lot. Doesn't this mean that a "main" function containing a major inner loop doesn't get the optimization it might deserve?

PS. I like you a lot but there's no way I'm going to "bare" with you. :-)
Date User Action Args
2016-05-02 21:13:15gvanrossumsetrecipients: + gvanrossum, brett.cannon, ncoghlan, vstinner, francismb, yselivanov
2016-05-02 21:13:15gvanrossumsetmessageid: <>
2016-05-02 21:13:15gvanrossumlinkissue26219 messages
2016-05-02 21:13:14gvanrossumcreate