[Pyrex] Need pyrex performance advice

David McNab david at rebirthing.co.nz
Sun May 9 14:28:11 CEST 2004


Hi,

I'm doing a wrap-job on the ALSA seq interface, and have hit on a 
performance dilemna.

The issue relates to the task of rendering incoming MIDI events as 
python-accessible objects.

With most wrappers, it's not too hard to render a struct; one just 
creates a tree of objects corresponding to the layers of the struct.

But here, things get challenging.

The problem is that the MIDI event struct is motherfreakin huge, with 
about 5 nested layers of structs and unions.

To rip up a C struct and build up a tree of python-accessible objects is 
just a matter of doing the menial work of declaring the python classes, 
instantiating, setting attribs etc.

However, when we consider that we can potentially be receiving several 
events per millisecond (eg, tripletted demisemiquavers on a single voice 
come in 2ms apart), we're looking at some harsh CPU thrashing for 
building up the python object tree, exacerbated by the client traversing 
the tree.

One solution I've thought of is to flatten the struct into a single 
dict, with a dotted notation for keys. For example:

   Pyrex: ev.data.note.channel

   Python: ev['data.note.channel']

and building up this dict with a pure-c pyrex method using Python/C API 
calls.

This, to me, feels a reasonable compromise, because we're only building 
up a single object - a dict - and avoiding the overhead of n levels of 
nested objects. Also, on the client side, there won't be n levels of 
getattr happening for attribute accesses.

Question - is this the best way to go? Or can someone offer a better 
solution, which will maximise speed, yet keep things simple for the client?

Thanks in advance for your advice

Cheers
David




More information about the Pyrex mailing list