bpo-36616: optimize handling of thread state in function call code - #12839
bpo-36616: optimize handling of thread state in function call code#12839jdemeyer wants to merge 1 commit into
Conversation
Sorry, something went wrong.
Thanks to Mark Shannon for the idea
scoder
left a comment
There was a problem hiding this comment.
I'd say, why not, but would also like to see at least some timings.
Sorry, something went wrong.
| PyObject **sp, *res; | ||
| sp = stack_pointer; | ||
| res = call_function(&sp, oparg, NULL); | ||
| stack_pointer = sp; |
There was a problem hiding this comment.
These stack pointer assignments look a bit like someone left them for documentation purposes, trying to make it clear what is allowed/supposed to happen with the pointer that is passed down.
I''m not saying that it's wrong to remove these assignments, just that Chesterton's Fence might apply.
Sorry, something went wrong.
There was a problem hiding this comment.
Those strange redirections were added because somebody wanted to use
register PyObject **stack_pointer;
and it's illegal to take the address of a register variable. But the register keyword is obsolete, compilers are now much more clever than they were before. Also, call_function() should be inlined and then the pointer isn't even a real pointer.
Sorry, something went wrong.
|
I did some more extensive benchmarks today and I'm no longer convinced that this actually improves anything. In any case, the gain would be very close to the measurement error and not significant. Parts of this could still make sense as a "clean up" patch, for example the strange assignment of stack_pointer around call_function(). But I don't want to fight that battle, so I'll just close this. |
Sorry, something went wrong.
Thanks to @markshannon for the idea.
This does various micro-optimizations for function calls in the bytecode interpreter to give a small increase in performance.
https://bugs.python.org/issue36616