Skip to main content
gamedev.net
🔒 Locked

SWIG or Boost::Python?

Started by ZeHa Jul 11, 2007 at 12:52 PM 3 replies 10.1k views
Original Post
ZeHa
ZeHa
Hello, I'd like to know if anyone of you experienced some differences between SWIG and Boost::Python, especially regarding performance? I already tested SWIG with some simple class, which worked nicely, and I think a big advantage is that I can just mention some .h files and they will be exposed just as they are inside my C++ code. If I want to restrict anything, I can still write a special .i file instead of just using the .h file. In Boost::Python I'd have to explicitley write every wrapped function, which would mean that I'd also have to change that when I change the class itself (meaning I'd have to maintain my class in three different domains (cpp, h, and wrapper), but normally I just want to expose the interface in exactly the same way as it is defined in the .h file. Now, are there any differences in performance? If there should be any significant ones (meaning my framerate would drop by 25% or something), I'd surely take another look on Boost::Python, but regarding features, I'd rather stick with SWIG (which actually rhymes, haha :) ). And are there any other differences? One big advantage for SWIG is that it can target a whole load of languages - I'm not sure if I'd use any of them, but it wouldn't restrict me in the future. Also, SWIG is just an executable and I wouldn't have issues with building/linking etc. So, what are your opinions?
Gorg
Gorg
The overhead from swig comes from the shadow classes(from the .py file generated by swig). You go through 1 extra Python call to get to the C++ code.

If you used a custom written extension or boost.python, the call would go straight to C++.

But, the extra overhead is small compared to the speed drop you get by simply writing things in Python. If you are slow, it won't be because of swig.
ZeHa
ZeHa
Thanks for your answer.

Actually, this was exactly what I wanted to hear :D
But I looked at the wrap output (the .cxx file), and it's really huge (3000 lines for a 36-line-class). There seems to be a lot going on (I'm not really able to decrypt everything there ;). So, I think there's a little more overhead than just the .py file...

However, is this also comparable to Boost? As far as I know, Boost uses macros... will they be expanded to the same amount of c code?
Gorg
Gorg
Yes, the boost stuff also expands to a lot of code, you just don't see it in your source code. Most of the stuff is attribute verification and conversion code, which you would need to write anyway if you did it all by hand.

Note that in the swig, the bigger functions are the overloaded ones. There are a lot of checking of parameters to select the right method. The checks are cheap, but as a rule I always make sure to minimise the amount of method overloading if the class will be used in a tight loop in python. So if you have a C++ class with an overloaded method, you don't have to modify it, you can simply rename the method overloads in the swig interface file.

If you check a simple method, it will look very close to what you would have needed to write if you did it yourself. Obviously with different names. Also, swig code is quite verbose which add in source file size, but not in final code size.

Also, the first chunk of the cxx file is the swig library. Swig is built to generate stand-alone module, so the library is always included in all the source file. Don't worry about it, the unused functions will get removed when linking.

Just enjoy the added productivity and be glad you did not have the write all that wrapping code by hand :)
viblo
viblo
Another option would be to use Py++: http://www.language-binding.net/pyplusplus/pyplusplus.html
I think they got a really good result switching from swig to py++ when wrapping Ogre (should be a link to that on the py++ site).

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.