Interface code is overhead. Extending the API in C to match exactly what you need and then wrapping the new API in XS will probably give you the "best" results. If you're going for speed you need as few cross-language calls as possible.

As an example, Audio::LADSPA wouldn't be able to generate sound in realtime if you needed a method call for each plugin and frame. That's why it takes buffers of floats and loops through them in C. Looping through half a million scalars a second in perl tends to slow your program down, but C will go through half a million floats in no time. That means it's probably better to write some "higher level" code that does the looping for you, so you only need 1 perl call for a batch of X floats.

Another thing I've noticed is that SWIG's OO interface code is horribly slow (especially when getting/setting properties). That's usually only an issue when the API doesn't really match what you're trying to do, but still it's something to be mindful of.

Cheers,
Joost.

You should have done the Perlish API stuff in wrappers written in Perl that called the SWIG / XS / Inline::C wrappers.

As Joost said, it depends.   In the project I was referring to, SWIG simply didn't provide enough flexibilty to get the (sometimes weird and dynamic) data structures converted into anything which would have remotely made sense in Perl. In other words, doing this part in Perl essentially would've meant returning big chunks of memory and then fiddling with pack()/unpack() on the Perl side to create the objects as needed. This certainly wouldn't have made it less fragile. Changing the C side wasn't an option, as it was a closed source third party library.

Well, I don't want to go into further details. I'd just like to point out that in the end, the flexibility of XS did allow me to write less and faster, i.e. more-to-the-point code than SWIG did.

Ugh. The "cool" factor of writing ugly, fragile code.

Did you notice the smiley?