Message264671
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:15 | gvanrossum | set | recipients:
+ gvanrossum, brett.cannon, ncoghlan, vstinner, francismb, yselivanov |
2016-05-02 21:13:15 | gvanrossum | set | messageid: <1462223595.18.0.413749955733.issue26219@psf.upfronthosting.co.za> |
2016-05-02 21:13:15 | gvanrossum | link | issue26219 messages |
2016-05-02 21:13:14 | gvanrossum | create | |
|