Ron Adam <ron3...@gmail.com> added the comment:
I think the time benefits I saw are dependent on how the C code is compiled.
So it may be different on different compilers or the same compiler with only a
very minor change.
Some of the things I've noticed...
A switch is sometimes slower if it has a "default:" block.
Moving "why = tstate->why_exit;" to just before the if helps a tiny bit.
why = tstate->why_exit;
if (why != WHY_EXCEPTION) {
Returning directly out of the WHY_YIELD case.
case WHY_YIELD:
return result;
These will be mostly compiler dependent, but they won't slow things down any
either.
What I was trying to do is clean up things a bit in ceval.c. Having the why
available on the frame can help by allowing some things to be moved out of
ceval.c where it makes sense to do that.
I'll post a new diff tonight with the why_exit moved back to the frame object
and the why's back to enums. Yes, I think the frame object is a good place for
it.
One of the odd issues is the opcode and why values sometimes need to be pushed
on the value stack. Which means it needs to be converted to a pyobject first,
then converted back after it's pulled off the stack. I'm looking for a way to
avoid that.
I also was able to make fast_block_end section simpler and more understandable
without making it slower. I think it was trying to be too clever in order to
save some lines of code. That makes it very hard to figure out by someone else.
But first I need to finish my Christmas shopping, I'll post a new patch tonight
when I get a chance. :-)
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13607>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
