Add 'time' order to tree.nodes()

It is sometimes useful to iterate over nodes in the tree in ‘time’ order, where we guarantee that the time of each node visited is >= the time of the previous one. Add this to the options in the order argument.

[benjeffery]

Thought I’d spend an evening looking at this to see what it’s like working with the codebase and as it had some friendly labels! I’ve implemented your trivial implementation above and an additional one using a priority queue from the heapq module. Code at https://github.com/benjeffery/tskit/commit/5feba1b4db5574436613e091b54470765f5e741d

To make it a fairer comparison between the methods, the order of traversal is the reverse of the one specified as this lets the priority queue method start at the root. Maybe there is a use case I am unaware of that strongly motivates the original order, but (unless sample_lists=True) you’d have to first traverse to get the leaves then work backwards.

I generated some trees to traverse with msprime.simulate(n) and then traversed over the first 20 trees. Code for the plot at https://gist.github.com/benjeffery/8c06f75effdc020b09a7ae0e2ab99246 So the priority queue method is pretty slow - this is due to it not being quite the right algorithm as we are not taking advantage of the fact that we only have need for a monotonic priority queue. In this case to doing something like a radix heap (e.g. https://github.com/iwiwi/radix-heap) would be better, but I couldn’t find anything to quickly drop into python.

But do we need to? The trivial method is faster than some of the existing methods, about a ~70-80% perf hit compared to levelorder and uses num_nodes * 2 * 8bytes of additional memory to do the sort.

Anyway, that’s how far I got for now, happy to document and then make a PR if needed.

[jeromekelleher]

Closed in #399 and #400