Re: $perl_extension ? require SWIG : require XS;

A few years ago I did a somewhat larger project, which aimed at providing a Perl scripting interface to some PDM (Product Data Management) system, which came with only a C/C++ API.

I got hooked on the 'saving implementation time' thing, and started doing it with SWIG. Problem was I wanted to implement a convenient, more perl-style UI than the original API did provide. In other words, the conversion wrappers had to do a bit more work than mapping simple data types. Well, to make it short, I wasn't able to figure out how to do this with SWIG, though I tried hard.

Ultimately, I ended up redoing the whole thing in XS. It wasn't that much more difficult, and the great advantage was that I essentially could do anything I wanted... So, if you should decide to go with SWIG (after having read the other responses), my advice would be to begin with wrapping the most complex function interface first (maybe after having acquainted yourself with a couple of preliminary easier exercises). This will minimize wasting time. (I had made the error to start with the simple things -- so I essentially did the project twice: 90% in SWIG, then once again in XS...)

Lastly, and somewhat less seriously: using XS would likely boost your ego with that warm and fuzzy feeling of having done it the way most 'real hackers' would do ;)

Comment on Re: $perl_extension ? require SWIG : require XS;

Replies are listed 'Best First'.
Re^2: $perl_extension ? require SWIG : require XS; (XS--) by tye (Sage) on Jan 06, 2007 at 21:20 UTC
You should have done the Perlish API stuff in wrappers written in Perl that called the SWIG / XS / Inline::C wrappers. Minimize the amount of code you write in SWIG / XS / Inline::C and you'll be happier in the long run (as will your users). That's why I advocate using Inline::C (it encourages simple, C-friendly interfaces which encourages writing the complex interface in Perl). Lastly, and somewhat less seriously: using XS would likely boost your ego with that warm and fuzzy feeling of having done it the way most 'real hackers' would do ;) Ugh. The "cool" factor of writing ugly, fragile code. - tye	[reply]
Re^3: $perl_extension ? require SWIG : require XS; (XS--) by Joost (Canon) on Jan 06, 2007 at 21:49 UTC
It depends. I'm working on a project that uses a lot of C & C++ code for convenience and speed, (but especially speed) and I would say, minimize the amount of interface code period. 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. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^3: $perl_extension ? require SWIG : require XS; (XS--) by almut (Canon) on Jan 06, 2007 at 23:39 UTC
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?	[reply]


Perl-Sensitive Sunglasses
	PerlMonks