Multi-threaded searching for speedier local search performance with big slow folders
In #821 (comment 754868) I observed a CPU usage pattern that seems to strongly suggest that Evolution's local search is single-threaded, where very little disk I/O happens and only one CPU core is used at 100% at any given time:
Having a multi-threaded search (even if it's something basic like looking at the list of messages to be searched and dividing it up equally into search domains) would allow dividing the "time the user spends waiting for search" by 4, 8, 16 or more on the typical modern computer. Even on a silly cheap dual-core CPU (hell, even a RaspberryPi is quad-core!) it would probably at least halve the search time, which is already a significant improvement.
For a 20-thousand-messages scenario, it would be the difference between waiting 10-20 seconds for results (which is problematic for being able to "try" various searches, as a user) vs waiting barely 2-3 seconds even for "full body text search".
Obviously this ticket is not about a "bug" on fire, it's an enhancement request, in the hope that someone seeing this wishes to try something on that front. But I really do think it might be the biggest speed improvement opportunity in Evolution, and it would be a killer feature! It would be fast-enough that no progressbar would be needed.