On Jun 17, 2008, at 4:54 AM, Stefan Behnel wrote: > 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.
Very good point. >>>> - 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... Yep. Note that I've looked into this and these can be huge (at least once a bit of analysis is done). >>>> 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... Yeah. I think this is mostly for ease of use of users--having to write .pxd's and .pyx's is natural for people coming from the C side of things, but not at all for those coming from Python. >> 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... If pxd files are around, only they would be used. This is only if they're not around. - Robert _______________________________________________ Cython-dev mailing list [email protected] http://codespeak.net/mailman/listinfo/cython-dev
