[Pyrex] [SPAM?] cdef __init__

[Stefan Behnel]

Hi,

Sam Rushing wrote:
> This is a performance problem we've had for quite a while at IronPort,
> and I think I've finally got a handle on it.
> Hopefully this is useful to other folks.
> 
> For a primer on the issue, grep through the archives for the thread
> "Cannot cdef __init__?".  Basically, constructing extension types is
> more expensive than it could be because it uses the normal python
> calling convention.  It's hard to make an object with a constructor as
> fast as PyList_New(), for example.
> 
> The attached hack supports a very specific form of fast constructor. 
> It's not ideal, and hopefully Greg can find a cleaner and better way to
> wedge it in than I did.
> 
> What the patch does is this: whenever Pyrex sees the following:
> 
>   <type> (arg0, arg1, ...)
> 
> It changes it to something like this:
> 
>   <type.__fast_init__> (AllocExtNode (<type>), arg0, arg1, ...)
> 
> ...if a cdef __fast_init__() method is defined.  A thoroughly
> uncivilized hack quietly adds a 'return self' to the end of this
> method's body, since this is something that's pretty easy to forget.


that's a good idea, I would totally love to have this as a language feature.
Especially, since it would still allow instantiating the extension type from
Python, but with a fast short cut from Pyrex code.

BTW, in lxml, we currently use factories instead of instantiating the class
with Python arguments. After calling the type without arguments, they simply
fill in the C-fields 'by hand'. This already avoids converting arguments to
Python objects and back. But it would still be faster if we could stay
straight in C for the whole thing.

Regards,
Stefan