[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