Robert Bradshaw wrote: > I'm not sure how much this would help (it would > some for sure), as I believe many of these iterators are already > written in C and it's a series of C calls. I think the biggest > savings is that > > cdef int i > for i, k in enumerate(L): > ... > > could increment i as a c int, and avoid all the tuple packing/ > unpacking.
... which is a rather big overhead for such a trivial iterator. The thing is, many iterators really do extremely simple things, but require all the tuple packing and function call indirection *on each iteration*. That's different from functions like max() or the Py2 zip(), which are called once and the do loads of stuff in C. Just look at these: http://docs.python.org/lib/itertools-functions.html The really simple ones are: enumerate, range, chain, count, islice, repeat count() and range() are actually equivalent in their iterable versions. But I think enumerate() and islice(), and maybe chain() might be worth optimising. > Likewise, the tuple packing/unpacking could be avoided for > zip (assuming the number of targets is equal to the number of > arguments). Which would be part of the compiler decision if this should run in plain C code or not. One thing to note: zip() is an iterator in Py3, which changes its semantics in that you must now call list(zip()) if you want to modify its arguments in place. And zip() is actually less trivial than the above mentioned ones. Maybe zip() is not worth being optimised. Stefan _______________________________________________ Cython-dev mailing list Cython-dev@codespeak.net http://codespeak.net/mailman/listinfo/cython-dev
