[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