Johannes Ahl-mann wrote:
> the program is supposed to manage bookmarks and i thought it would be a
> good idea to represent the bookmarks as a tree (with folders as internal
> nodes and bookmarks as leaves).
> so, a tree is never going to hold more than say 2000 nodes and is going
> to be rather w
> You don't really give the complete story so it's hard to tell what
> exactly is going on. For example, I would assume the recursion is
> calling the same method (i.e., depthFirstIterator1 or
> depthFirstIterator2), but then you posted separate timing information
> for a "recursive helper function
Johannes Ahl-mann wrote:
> 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.
Aside from the recursion question...
You don't really give the complete story so it's hard to tell what
exac
Johannes Ahl-mann <[EMAIL PROTECTED]> wrote:
> a non-recursive solution to traversing a recursive data type is bound to
> get ugly, isn't it?
Not necessarily: sometimes using an explicit stack can be quite pretty,
depending. E.g.:
def all_leaves(root):
stack = [root]
while stack:
> 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
> overhea
Johannes Ahl mann wrote:
> i am in the process of profiling an application and noticed how much
> time my depth first generator for walking a tree data structure took.
>
> i wrote the same thing as a recursive function producing an array, and
> this non-generator version is nearly 10 times faster!
sorry, forgot to post the profiling info for the recursive helper
function.
but generator is still FAR slower...
4095/10.0500.0000.1200.120 file.py:135(rek)
Johannes
--
http://mail.python.org/mailman/listinfo/python-list
