[Python-ideas] multiple objects handling

[Scott Dial]

On 8/12/2011 4:49 PM, Peter V. Saveliev wrote:
> I have a stream of objects, each of dictionary type. Actually, they
> represent events and are emitted by an asynchronous thread.
> 
> The issue is that a method call is slower that jump within one function.
> But a dictionary lookup is faster than «if/elif» statements (if I have a
> lot of variants and do not want to rebuild B-like tree of «if»
> statements by hands).
> 
> Is there a way to combine these methods? Can I create a dictionary of
> jump instructions?
> 
> So far I see that JUMP_ABSOLUTE and JUMP_FORWARD take an integer as a
> parameter. It is reasonable, 'cause it is faster for if/elif/for etc.
> statements. And thus I can not use a dictionary to store offsets and
> then use them for one JUMP instruction.
> 
> But can we have another separate codeop, e.g. something like
> JUMP_BY_TOS, that takes offset (or absolute address) from the top of the
> stack?
> 
> Anyway, it can significantly speed up any stream parsing.
> 

Really? Your runtime is dominated by a *single* dict lookup and a
*single* method call? What do you do with these objects that takes so
little time that such a micro-optimization will have a "significant
speed up" to your program?

Have you actually profiled the performance of your program? I would
guess that the time spent dispatching through a dictionary is dwarfed by
the time spent constructing those event objects and the ultimate
processing of them.

> But can we have another separate codeop, e.g. something like
> JUMP_BY_TOS, that takes offset (or absolute address) from the top of the
> stack?

How would you use such a opcode? There is no syntax available that would
allow you to get the offset (or absolute address) of any given line in a
function. To have a "goto" statement, you have to have labels, we don't
have those either.

Or, are you proposing that CPython optimize large if/elif blocks into
dispatch tables? That sounds more interesting, but the performance win
would have to worth the additional code complexity.

-- 
Scott Dial
scott at scottdial.com