On Sat, Nov 1, 2008 at 12:48 PM, Paul Melis <[EMAIL PROTECTED]> wrote: > I'd like to see proof of the claim that SWIG's wrapper code is > inefficient. In my experience it is not more inefficient than what, for > example, boost.python via Py++ provides.
I was curious about the claims of SWIG's inefficiency, so I did a quick little experiment. As I said in an earlier post, I normally work with boost.python, but I have a partial, proof-of-concept SWIG wrapper for my project as well (done to explore using the project from Java). I quickly built a python wrapper from that and then wrote a simple test : ------- t1 = time.time() for i in range(50000): for j in range(m.getNumAtoms()): # <- m is a wrapped object a = m.getAtomWithIdx(j) # <- returns a reference to an existing wrapped object t2 = time.time() print 'Part 1: %.2f'%(t2-t1) t1 = time.time() for i in range(50000): m = RDKFuncs.MolFromSmiles('C') # <- returns a new wrapped object t2 = time.time() print 'Part 2: %.2f'%(t2-t1) ------- m.getNumAtoms() returns 9, so the inner loop in Part 1 is called 450K times. I tested this on an ubuntu linux machine using the boost.python from boost v1.35, g++ 4.2.4, and swig 1.3.34 Approximate run time for Part 1: boost : 2.1 seconds SWIG : 2.4 seconds Approximate run time for Part 2: boost : 4.7 seconds SWIG : 3.9 seconds Expanding Part 1 to see what happens when I return an int from a wrapped function: ------- t1 = time.time() for i in range(50000): for j in range(m.getNumAtoms()): # <- m is a wrapped object a = m.getAtomWithIdx(j) # <- returns a reference to an existing wrapped object n = a.getAtomicNum() # <- returns an integer t2 = time.time() print 'Part 1a: %.2f'%(t2-t1) ------- Approximate run time for Part 1a: boost : 3.5 seconds SWIG : 3.9 seconds I don't know if this is even remotely generalizable, but based on this simple test, I don't see a runtime penalty associated with using SWIG; in fact, at least in this very simple test, the wrapper generated by SWIG is somewhat faster than that generated using my boost.python wrapper. This isn't very artificial test isn't enough to make me want to change wrapping strategies to SWIG from boost.python. If anything is going to do that it's going to be the ability to support languages other than Python. Probably not worth two cents, but I thought I'd toss them in anyway. -greg _______________________________________________ Cplusplus-sig mailing list Cplusplus-sig@python.org http://mail.python.org/mailman/listinfo/cplusplus-sig