SWIG overhead

2007-02-01 Thread Bart Ogryczak
Hi, I´m looking for some benchmarks comparing SWIG generated modules with modules made directly with C/Python API. Just how much overhead does SWIG give? Doing profile of my code I see, that it spends quiet some time in functions like _swig_setattr_nondinamic, _swig_setattr, _swig_getattr. --

Re: SWIG overhead

2007-02-01 Thread Roman Yakovenko
On 1 Feb 2007 02:21:35 -0800, Bart Ogryczak [EMAIL PROTECTED] wrote: Hi, I´m looking for some benchmarks comparing SWIG generated modules with modules made directly with C/Python API. Just how much overhead does SWIG give? Doing profile of my code I see, that it spends quiet some time in

Re: SWIG overhead

2007-02-01 Thread Phil Thompson
On Thursday 01 February 2007 10:21 am, Bart Ogryczak wrote: Hi, I´m looking for some benchmarks comparing SWIG generated modules with modules made directly with C/Python API. Just how much overhead does SWIG give? Doing profile of my code I see, that it spends quiet some time in functions

Re: SWIG overhead

2007-02-01 Thread Bart Ogryczak
On Feb 1, 12:12 pm, Phil Thompson [EMAIL PROTECTED] wrote: On Thursday 01 February 2007 10:21 am, Bart Ogryczak wrote: Hi, I´m looking for some benchmarks comparing SWIG generated modules with modules made directly with C/Python API. Just how much overhead does SWIG give? Doing profile

Re: SWIG overhead

2007-02-01 Thread Diez B. Roggisch
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

Re: SWIG overhead

2007-02-01 Thread Bart Ogryczak
On Feb 1, 12:48 pm, Diez B. Roggisch [EMAIL PROTECTED] 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,

Re: SWIG overhead

2007-02-01 Thread Diez B. Roggisch
Bart Ogryczak wrote: On Feb 1, 12:48 pm, Diez B. Roggisch [EMAIL PROTECTED] 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

Re: SWIG overhead

2007-02-01 Thread Chris Mellon
On 2/1/07, Diez B. Roggisch [EMAIL PROTECTED] wrote: Bart Ogryczak wrote: On Feb 1, 12:48 pm, Diez B. Roggisch [EMAIL PROTECTED] 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

Re: SWIG overhead

2007-02-01 Thread John Roth
On Feb 1, 3:21 am, Bart Ogryczak [EMAIL PROTECTED] wrote: Hi, I´m looking for some benchmarks comparing SWIG generated modules with modules made directly with C/Python API. Just how much overhead does SWIG give? Doing profile of my code I see, that it spends quiet some time in functions like

Re: SWIG overhead

2007-02-01 Thread skip
John Bottom line: the c-types module was a lot smaller, in Python, and John completely comprehensible. And while I didn't measure the John performance, I doubt if it was slower. One advantage SWIG (or Boost.Python) has over ctypes is that it will work with C++. Skip --

Re: SWIG overhead

2007-02-01 Thread Roman Yakovenko
On 2/1/07, Chris Mellon [EMAIL PROTECTED] wrote: As I understand it, part of the Boost.Python internals is a C++ wrapper over the Python C api, That's true. and there's no separate code generation phase because it uses template magic to generate the wrappers. Well, actually it depends on the