Author alexandre.vassalotti
Recipients ajaksu2, alexandre.vassalotti, bboissin, blaisorblade, christian.heimes, djc, facundobatista, lemburg, pitrou, ralph.corderoy, rhettinger, skip.montanaro, theatrus
Date 2009-01-04.18:52:25
SpamBayes Score 0.0173287
Marked as misclassified No
Message-id <1231095163.82.0.00627768954618.issue4753@psf.upfronthosting.co.za>
In-reply-to
Content
> Removing the switch won't be possible unless we change the semantic
> EXTENDED_ARG. In addition, I doubt the improvement, if any, would worth
> the increased complexity.

Nevermind what I have said. I managed to remove switch pretty easily by
moving opcode fetching in the FAST_DISPATCH macro and abstracting the
control flow of the switch. There is no speed difference on pybench on
x86; on x86-64, the code is slower due to the opcode fetching change.

> I patched ceval.c to minimize f->last_i manipulations in the dispatch
> code.  On x86, I got an extra 9% speed up on pybench. However, the
> patch is a bit clumsy and a few unit tests are failing. I will see
> if I can improve it and open a new issue if worthwhile.

Nevermind that too. I found out f->last_i can be accessed anytime via
frame.getlineno(). So, you cannot really change how f->last_i is used
like I did.
History
Date User Action Args
2009-01-04 18:52:44alexandre.vassalottisetrecipients: + alexandre.vassalotti, lemburg, skip.montanaro, rhettinger, facundobatista, pitrou, christian.heimes, ajaksu2, djc, ralph.corderoy, bboissin, blaisorblade, theatrus
2009-01-04 18:52:43alexandre.vassalottisetmessageid: <1231095163.82.0.00627768954618.issue4753@psf.upfronthosting.co.za>
2009-01-04 18:52:25alexandre.vassalottilinkissue4753 messages
2009-01-04 18:52:25alexandre.vassalotticreate