SWIG overhead

[Diez B. Roggisch]

Bart Ogryczak wrote:

> On Feb 1, 12:48 pm, "Diez B. Roggisch" <d... at nospam.web.de> wrote:
>> > Yeah, found that one googling around. But I haven´t fund anything more
>> > up to date. I imagine, that the performance of all of these wrappers
>> > has been improved since then. But the performance of Python/C API
>> > would too?
>> > Anyways, it´s not about exact number, it´s more about taking decision
>> > if doing rewrite is worth it´s time.
>>
>> The wrappers essentially create the boilerplate-code that invokes the
>> Python C-API. So whatever improvements the latter has been developed, the
>> wrappers will benefit from it.
> 
> Without doubt it´s true in case of SWIG, but if I understand
> Python.Boost documentation correctly, it does *not* use Python/C API.

It has to. In the end, marshalling data between e.g. python datastructures
and C++ is done that way.
 
>> I doubt that there are major performance penalties associated with any of
>> them.
> 
> Take a look at pages 23 and 24 of http://people.web.psi.ch/geus/talks/
> europython2004_geus.pdf

Ok, I see. I really wonder what SWIG does.

> Well, SWIG is easy to use. But I´ve gotta make hundreds of millions of
> calls, which do tasks as simple, as getting one int from an array and
> returning it. With functions that simple SWIG´s overhead seems to be a
> problem.

Still I think you should first use wrappers for ease of use. Then when you
hit a performance bottleneck, it might be worth  wrapping that class
manually. However, it _might_ of course be that this isn't integrating too
seamless with the wrapped classes, but I can't say anything about that
really.

Diez