2012/3/11 Stefan Behnel <stefan...@behnel.de>: > mark florisson, 11.03.2012 07:44: >> - better type inference, that would be enabled by default and again >> handle thing like reassignments of variables and fallbacks to the >> default object type. With entry caching Cython could build a database >> of types ((extension) classes, functions, variables) used in the >> modules and functions that are compiled (also def functions), and >> infer the types used and specialize on those. Maybe a switch should be >> added to cython to handle circular dependencies, or maybe with the >> distutils preprocessing it can run all the type inference first and >> keep track of unresolved entries, and try to fill those in after >> building the database. For bonus points the user can be allowed to >> write plugins to aid the process. > > That would be my favourite. We definitely need control flow driven type > inference, local type specialisation, variable renaming, etc. Maybe even > whole program (or at least module) analysis, like ShedSkin and PyPy do for > their restricted Python dialects. Any serious step towards that goal would > be a good outcome of a GSoC. >
I think we should be careful here and try to avoid making Cython code more complicated. > There's also better support for PyPy through its cpyext C-API layer, but > that currently involves much more work on PyPy than on Cython, including a > lot of performance optimisation on their side. And there doesn't seem to be > much interest in the PyPy project for doing this. > I'm intrested in function/method call inlining based on CF analysis and on generic cyfunction's signature. I'll do some benchmarks to see how much do we get from this optimization. -- vitja. _______________________________________________ cython-devel mailing list cython-devel@python.org http://mail.python.org/mailman/listinfo/cython-devel