Mariachi has scaling issues caused by the fact that it doesn't arbitarily break stuff up over month boundries because, well, threads don't stop just because it's the end of the month. That plus threading meant that it slowed to a crawl around the $n thousand messages mark, even when adding messages incrementally. This is sub-optimal.
A while back
Ben Trott submitted patches to make Mariachi
Atom aware which, AFAIK were never applied. That weekend I decided it would be better to let users write plugins without needing us to patch the main branch and ended up completely rewrting Mariachi to be
Email::Store (for speed) and plugin (for extensibility) based which was nifty but, incredibly, even slower than before.
*sigh*
Then I got caught up in
Buscador and the idea fizzled out but I think i might have another crack at refactoring
Mariachi back to be plugin based and make some changes (one thread per thread page, oldest mails at chronological1.html and the latest as chronological${n}.html) to amke it faster and more intuitive (each message would be at ${message-id}.html). Then each plugin could take care of its own caching if needs be and how ever it wants - maybe using Netscape style
summary files or
DBM::Deep