[Pyrex] possible bug with public function declarations

Greg Ewing greg.ewing at canterbury.ac.nz
Tue Feb 22 02:37:43 CET 2005


Robby Dermody wrote:

> One of my main worries was that the overhead of calls between methods of
> an extension type (and methods between extension types) would be
> undesirable. This is true if the method being called is a Python method.
> However, if the method is a C method, the overhead looks negligible.
> Here's some C code generated when MyDS.testfuncC() is being called from
> a function in the same extension type:
> 
>   __pyx_1 = ((struct __pyx_vtabstruct_12dataservices_MyDS
> *)__pyx_v_self->__pyx_vtab)->testfuncC(__pyx_v_self); if (!__pyx_1)
> {__pyx_filename = __pyx_f[0]; __pyx_lineno = 88; goto __pyx_L1;}
>   Py_DECREF(__pyx_1); __pyx_1 = 0;
> 
> I see two extra pointer dereferences and a possible Py_DECREF over what
> I would have had through a direct top level C function call,

And the Py_DECREF is only because the method you're calling
returns a Python type. If it returned a C type you wouldn't
even have that.

I do appreciate the desire to be able to separately
compile parts of a single module, however. I don't have
any philosophical objection to that, I just haven't put
a lot of thought into how to support it cleanly. Maybe in
a future version.

Thanks for your comments,

-- 
Greg Ewing, Computer Science Dept, +--------------------------------------+
University of Canterbury,	   | A citizen of NewZealandCorp, a	  |
Christchurch, New Zealand	   | wholly-owned subsidiary of USA Inc.  |
greg.ewing at canterbury.ac.nz	   +--------------------------------------+



More information about the Pyrex mailing list