This reverts commit c7b28419ab.
The reverted change fails to sort threads correctly when there is an
empty container, serving as a parent to orphan messages, in the thread
tree as demonstrated by the test in commit f49296759e ("tests:
threads: Test if orphan message promotes its thread").
Also, the reverted commit introduces a performance hit. The time it
takes to sort threads has increased roughly by a factor of 4.
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):
4967.692519 task-clock (msec) # 1.000 CPUs utilized ( +- 0.14% )
4.969247128 seconds time elapsed ( +- 0.14% )
With the reverted 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):
1231.761588 task-clock (msec) # 0.996 CPUs utilized ( +- 1.02% )
1.236209133 seconds time elapsed ( +- 1.08% )
The benchmark was ran on a maildir with ~16k messages:
$ mu find maildir:/INBOX | wc -l
16503
The problem was that once a container got a parent, it did not change it anymore
due to the child_elligible condition, but the parent might have been assigned
from an incomplete References sequence.
Now, we make sure the last reference gets to be the message's parent (following
the JWZ's algorithm), reparenting the message if necessary. This makes sense, as
the last parent-child relationship (between last ref and the message) is the
most reliable piece of info here.
Instead of child_elligible, we now only check that the new parent is not a
descendant of the current message, to prevent making a loop. Everything else is
fine, as it only moves a subtree around.
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%.
