Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cython calls ExtType.__init__() as Python function #560

Open
robertwb opened this issue May 6, 2008 · 6 comments
Open

Cython calls ExtType.__init__() as Python function #560

robertwb opened this issue May 6, 2008 · 6 comments

Comments

@robertwb
Copy link
Contributor

robertwb commented May 6, 2008

When subclasses of extension types call the __init__() method of their supertype, Cython generates code that looks up the "__init__" attribute of the instance and then calls it through Python using arg tuple/kwargs. This is because the special __init__() method ("tp_init" slot) uses this call signature.

Cython should recognise calls to this method and at least call it directly.

In the (presumably very common) case that the arguments do not use starargs, a more advanced approach would be to split the __init__() method into an internal plain C-function replacement and a tp_init wrapper, and then call the internal function directly, without doing any tuple packing etc. Not sure if it's worth it, though, as the call is already preceded by an (expensive) object allocation.

Migrated from http://trac.cython.org/ticket/3

@robertwb
Copy link
Contributor Author

robertwb commented May 6, 2008

@robertwb changed owner from robertwb to somebody
commented

@robertwb
Copy link
Contributor Author

@garyfurnish commented

One of the first things I do is make my own c wrappers for creating objects. Even with the expensive new call the savings it noticeable.

@robertwb
Copy link
Contributor Author

@robertwb changed milestone to wishlist
commented

@robertwb
Copy link
Contributor Author

robertwb commented Mar 6, 2009

scoder changed description from

When subclasses of extension types call the init() method of their supertype, Cython generates code that looks up the "init" attribute of the instance and then calls it through Python using arg tuple/kwargs. This is because the special init() method ("tp_init" slot) uses this call signature.

Cython should recognise calls to this method and at least call it directly.

In the (presumably very common) case that the arguments do not use starargs, a more advanced approach would be to split the init() method into an internal plain C-function replacement and a tp_init wrapper, and then call the internal function directly, without doing any tuple packing etc. Not sure if it's worth it, though, as the call is already preceded by an (expensive) object allocation.

to

When subclasses of extension types call the __init__() method of their supertype, Cython generates code that looks up the "__init__" attribute of the instance and then calls it through Python using arg tuple/kwargs. This is because the special __init__() method ("tp_init" slot) uses this call signature.

Cython should recognise calls to this method and at least call it directly.

In the (presumably very common) case that the arguments do not use starargs, a more advanced approach would be to split the __init__() method into an internal plain C-function replacement and a tp_init wrapper, and then call the internal function directly, without doing any tuple packing etc. Not sure if it's worth it, though, as the call is already preceded by an (expensive) object allocation.
commented

The same idea is reported in http://trac.cython.org/ticket/141. This should use cpdef semantics.

@robertwb
Copy link
Contributor Author

robertwb commented Mar 8, 2009

scoder commented

The same applies to other special methods like __call__. (noted here to close http://trac.cython.org/ticket/141 as a duplicate)

@robertwb
Copy link
Contributor Author

scoder commented

The test in tests/run/special_methods_T561.pyx has some test code for this:

6ae0222

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant