[Cython] Dev days status

[Stefan Behnel]

Robert Bradshaw <robertwb at ...> writes:
> On Jun 16, 2008, at 11:23 PM, Stefan Behnel wrote:
> > One thing I'd add is an optimisation for normal object-returning  
> > functions
> > that do not have a return statement, i.e. that do not really return  
> > anything
> > but exceptions. Here, we could change the signature internally to  
> > returning a
> > bint instead (normal return or exception), which avoids the INCREF/ 
> > DECREF None
> > overhead for the return value.
> 
> That is a good idea, though might mess up the signature (e.g. for  
> cdef methods that may be overridden).

It would be fine for functions, though, and that's where I'd expect the 
biggest impact anyway, e.g. when inlining short functions.


> >> - Using the .pyx file for "cimport" when a .pxd file is unavailable
> >> (basically auto-generation of pxd files).
> >
> > I'm not so sure about that one. This basically means cimporting  
> > from .pyx
> > files, which might really lead to a performance drop of the  
> > compiler (remember
> > that the slowest thing is still the scanner).
>
> I imagine we would want to cache this, perhaps in an easier to parse  
> format that .pxds are now (as parsing them can take a while too).

Like a pickled .pxd parse tree? That might obviously change over Cython 
versions, but if it's only for caching...


> >> These last two have the disadvantage that the dependancy tree could
> >> become much more connected, so we would provide a way to disable
> >> them.
> 
> There are several ways it becomes tighter. First, one can import  
> rather than cimport when one doesn't need speed and doesn't want to  
> create a compile-time dependancy (e.g. like in a huge project like  
> Sage). Secondly, everything in the file gets cimported, not just the  
> interface exposed by the .pxd.

I actually think a lot of stuff would never be cimported, think of the Python 
stdlib, for example. I mean, we may still see the day where C extensions in 
the stdlib ship with .pxd's, but until then...


> Thirdly, any time the .pyx file  
> changes, it needs to be checked (instead of only on .pxd changes).

True, and that means tracking and parsing all included .pxi files. I actually 
think that was the reason why .pxd files were introduced in the first place. 
Importing from .pyx files might not be that a good idea after all...

Stefan