Robert Bradshaw <[EMAIL PROTECTED]> 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 _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
