New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fold compare operators on constants (peephole) #70909
Comments
Missed peephole optimization: |
Do you have any numbers on how common constant comparisons are in real code? |
Hi, it looks like the author of the peephole optimizer is Raymond Hettinger and he doesn't look to want to handle too many cases, he prefers to keep the code simple. FYI I reimplemented recently the peephole optimizer in pure Python as part of the bytecode project: I didn't write it to replace the C implementation, it was more a tool to discuss modifying bytecode (when discussing the PEP-511). More generally, there is an ongoging discussion of rewriting the peephole optimizer to work on the AST rather than working on the Python code. The FAT Python implements that in pure Python: FAT Python is more than a peephole optimizer, it's more a framework to implement more optimizations. Well, take a look. |
In my experience, it almost never occur in real application. But it's common when you start with a constant propogation optimization:
If you extend constant propagation to things like os.name, it's even more common, but it requires to specialize the code, to disable optimization if os.name is modified (that's one feature provided by FAT Python). |
AFAICT, the cases the OP listed would be rarely found in real code. Victor is correct is saying that we want to limit the scope of the peepholer to the most useful cases. He is also correct in saying that we've long desired constant folding to be moved upstream to the AST and don't want to go further down the path of doing more work at the bytecode level. Ideally, the only optimizations at the peephole level would be limited to rejuggling opcodes into cheaper execution sequences without regard to higher level object semantics. I recommend rejecting this and suggesting that more effort be focused on the AST optimizations. |
Nice work on getting this running, Alexander. However, as Victor and Raymond noted, we're looking to head in a different direction with our bytecode optimisation efforts, which is to better support pluggable AST level optimisations that can make more assumptions about the runtime environment. If this is a topic you'd like to explore further, then in addition to Victor's FAT Python project, you may also be interested in his proposals to add some supporting infrastructure for that to Python 3.6:
|
Hi all, this is my first patch to Python. |
I submitted a patch years ago that addressses the ''x,y = 1, 2' case: 2016-04-10 5:08 GMT+00:00 Alexander Marshalov <report@bugs.python.org>:
|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: