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 ron_adam
Recipients benjamin.peterson, jcea, meador.inge, ncoghlan, ron_adam, terry.reedy
Date 2011-12-21.17:59:48
SpamBayes Score 5.2509386e-11
Marked as misclassified No
Message-id <>
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. :-)
Date User Action Args
2011-12-21 17:59:49ron_adamsetrecipients: + ron_adam, terry.reedy, jcea, ncoghlan, benjamin.peterson, meador.inge
2011-12-21 17:59:49ron_adamsetmessageid: <>
2011-12-21 17:59:48ron_adamlinkissue13607 messages
2011-12-21 17:59:48ron_adamcreate