When the root set contains only one empty container with one child
first promote the child container to the root set and only then
remove the empty parent container so that the root set never goes
empty.
Also make mu_container_splice_children() do only one thing, that is
promote one container's children to be another container's siblings.
The resultant childless container is no longer removed by this
function.
Fixes#460.
Traverse the container tree depth first and for each container find
the node in the subtree rooted at this container which comes first in
the descending sort order. Remember it as the subtree leader. Then,
while sorting siblings, compare their subtree leaders instead of the
sibling containers themselves.
IOW, make threads containing the newest message float to the top when
sorting by date in the descending order.
There is no significant performance degradation when sorting a
mailbox with ~16k messages:
$ mu find maildir:/INBOX | wc -l
16503
Current state:
$ perf stat --event=task-clock --repeat=10 -- \
mu find maildir:/INBOX -n 1 -t > /dev/null
Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):
1231.761588 task-clock (msec) # 0.996 CPUs utilized ( +- 1.02% )
1.236209133 seconds time elapsed ( +- 1.08% )
With patch applied:
$ perf stat --event=task-clock --repeat=10 -- \
mu find maildir:/INBOX -n 1 -t > /dev/null
Performance counter stats for 'mu find maildir:/INBOX -n 1 -t' (10 runs):
1459.883316 task-clock (msec) # 0.998 CPUs utilized ( +- 0.72% )
1.462540088 seconds time elapsed ( +- 0.77% )
This implements https://github.com/djcb/mu/issues/164.
mu_container_append_siblings was showing up high in profiles as it has to
walk chains of next->next->next->... pointers to find the last one. we now
cache the last link in the chain. for listing ~ 23K messages, this saves
about 20%.