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 blaisorblade
Recipients ajaksu2, alexandre.vassalotti, bboissin, blaisorblade, christian.heimes, djc, facundobatista, lemburg, pitrou, ralph.corderoy, rhettinger, skip.montanaro, theatrus
Date 2009-01-05.02:39:44
SpamBayes Score 0.13343771
Marked as misclassified No
Message-id <1231123186.23.0.540731132493.issue4753@psf.upfronthosting.co.za>
In-reply-to
Content
@alexandre: if you add two labels per opcode and two dispatch tables,
one before (like now) and one after the parameter fetch (where we have
the 'case'), you can keep the same speed.
And under the hood we also had two dispatch tables before, with the
switch, so it's not a big deal; finally, the second table is only used
in the slow path (i.e. EXTENDED_ARG, or when additional checks are needed).

About f->last_i, when I have time I want to try optimizing it. Somewhere
you can be sure it's not going to be used.
But you have some changes about that in the abstract-switch patch, I
think that was not intended?
History
Date User Action Args
2009-01-05 02:39:46blaisorbladesetrecipients: + blaisorblade, lemburg, skip.montanaro, rhettinger, facundobatista, pitrou, christian.heimes, ajaksu2, alexandre.vassalotti, djc, ralph.corderoy, bboissin, theatrus
2009-01-05 02:39:46blaisorbladesetmessageid: <1231123186.23.0.540731132493.issue4753@psf.upfronthosting.co.za>
2009-01-05 02:39:45blaisorbladelinkissue4753 messages
2009-01-05 02:39:44blaisorbladecreate