bad generator performance

Johannes Ahl-mann softpro at gmx.net
Sun Feb 6 08:06:43 EST 2005


> Um. Under my definition of "recursion", you haven't really removed
> recursion in the generator version. That is, you're still calling the
> depthFirstIterator method upon each iteration--you've just changed from
> list-concatenation to yielding instead, which trades off list-management
> overhead for closure-maintenance overhead. 
yup, i am aware that my generator version is also recursive. but what i
thought this would do is "generate" a lazy list of return values (in
theory at least).
but this still doesn't explain why the yielding is so much slower than
the list concatenation!

> A truly non-recursive
> implementation would probably exist outside of whatever class you've got
> this method in, and would keep its own pointer to the current node as it
> traversed the tree.


i loved the generator solution because it was short, concise and lazy,
but if i am going to write the closure/continuation/recursion handling
manually i'd rather go with the memory-consuming list concatenation...
a non-recursive solution to traversing a recursive data type is bound to
get ugly, isn't it?

i just wondered if there was a concise, clean way of doing this with
generators which i had overlooked, or whether there was some blatant
mistake in my code.

thx,

Johannes



More information about the Python-list mailing list