[C++-sig] new to python; old to C++

Greg Landrum greg.landrum at gmail.com
Sun Nov 2 17:05:39 CET 2008


On Sat, Nov 1, 2008 at 12:48 PM, Paul Melis <paul at pecm.nl> 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


More information about the Cplusplus-sig mailing list