Re^3: A more elegant way to filter a nested hash?

The biggest savings is the call stack. In general, the overhead involved in moving into and out of subroutines is not negligible -- profile if you need to know the cost in your particular scenario. Iterative solutions with work queues can also be much more intelligible and may scope to your data more elegantly.

However, from a true optimization perspective, if it runs and if it's documented, your effort is likely better spent improving a different chunk of code rather than worrying about aesthetics.

#11929 First ask yourself `How would I do this without a computer?' Then have the computer do it the same way.

Comment on Re^3: A more elegant way to filter a nested hash?

Replies are listed 'Best First'.
Re^4: A more elegant way to filter a nested hash? by LanX (Saint) on May 31, 2018 at 18:22 UTC
I agree with most of what you said. IMHO recursive solutions are easier to write and maintain, I'd only translate them to iterative if performance mattered. Point is you still need some kind of call stack* which needs to be simulated then. Cheers Rolf _{(addicted to the Perl Programming Language :) Wikisyntax for the Monastery} *) in this case the last positions in the tree and remaining keys for each sub hash.	[reply]

Replies are listed 'Best First'.

Re^4: A more elegant way to filter a nested hash?
by LanX (Saint) on May 31, 2018 at 18:22 UTC

IMHO recursive solutions are easier to write and maintain, I'd only translate them to iterative if performance mattered.

Point is you still need some kind of call stack* which needs to be simulated then.

Cheers Rolf
_{(addicted to the Perl Programming Language :)

Wikisyntax for the Monastery}

*) in this case the last positions in the tree and remaining keys for each sub hash.

[reply]