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