On May 13, 2008, at 12:07 PM, Stefan Behnel wrote:
>
>> I do think optimizing enumerate/zip/etc is feasible and probably
>> worthwhile.
>
> I'm just concerned about too many special cases in the optimiser.
>
> If we start optimising these (and I would prefer giving range(), zip
> () &
> friends their Py3 iterator semantics in this case), we should come
> up with
> a generic way to support iterator chaining in C code rather than
> making
> the looping code even more complicated and special casing.
Yes, I certainly agree. This is an area where the "visitor" paradigm
makes much more sense.
> When we loop over a chain of iterators, this example
>
> for i,k in enumerate(range(100)):
> l += i*k
>
> could become something like this:
>
> c_range_state = c_range_new(100)
> c_enumerate_state = c_enumerate_new()
>
> while 1:
> temp1 = c_range_next(c_range_state); if (!temp1) ...
> temp2 = c_enumerate_next(c_enumerate_state, temp1); if (!
> temp2) ...
> i,k = temp2
> l += i*k
> c_range_free(c_range_state)
> c_enumerate_free(c_enumerate_state)
>
> Maybe a subclassable ForLoopNode class with a way to generate the
> start,
> body and end code of a loop might be an idea. That way, we could
> chain the
> subclasses that know how to loop over a list, range(), enumerate(),
> etc.,
> and we wouldn't even need malloc as everything could live in local
> variables.
An interesting idea. 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. Likewise, the tuple packing/unpacking could be avoided for
zip (assuming the number of targets is equal to the number of
arguments).
- Robert
_______________________________________________
Cython-dev mailing list
[email protected]
http://codespeak.net/mailman/listinfo/cython-dev
