Code that ought to run fast, but can't due to Python limitations.

[Hendrik van Rooyen]

"Paul Rubin" <http://phr.cx@NOSPAM.invalid> wrote:

> The series of tests is written that way because there is no case
> statement available.  It is essentially switching on a bunch of
> character constants and then doing some additional tests in each
> branch.
> 
> It could be that using ord(c) as an index into a list of functions
> might be faster than a dict lookup on c to get a function.  I think
> John is hoping to avoid a function call and instead get an indexed
> jump within the Python bytecode for the big function.

I agree about the ord(c). However, avoiding the function call
is, I think, right now, in the realms of wishful thinking.

I cannot see how you could avoid a python function call - even if he
bites the bullet and implements my laborious scheme, he would still 
have to fetch the next character to test against, inside the current state.

So if it is the function calls that is slowing him down, I cannot
imagine a solution using less than one per character, in which
case he is screwed no matter what he does.

But wait - maybe if he passes an iterator around - the equivalent of
for char in input_stream...
Still no good though, unless the next call to the iterator is faster
than an ordinary python call.

- Hendrik