Re: [Mutt] #2981: header_cache: opening a changed Maildir takes way
#2981: header_cache: opening a changed Maildir takes way longer than it
Changes (by pdmef):
* keywords: => header cache, performance
* summary: header_cache: opening a changed Maildir takes way longer than
it
should => header_cache: opening a changed Maildir
takes way longer than it
* component: mutt => header cache
* milestone: => 1.6
Comment:
What's your value of $mail_check? What db backend do you use? Any relevant
config part (i.e. is it the same with mutt -nF /dev/null -e ...)? Can you
please attach the output of 'mutt -v'?
Is there any chance you can build and test from a modified source?
If yes: in the case where the mailbox is open and you feed new mail in,
mutt needs to rescan the whole folder. For ignoring messages it knows
already, it uses hash tables with 1031 rows. When you only have a few
mails in new/ it shouldn't matter much, but when you have 70k mails in
cur/ and feed in a few, it needs to first go through with readdir(), and
then fill that 1031 row hash table with lots collisions, thus walking
quite long linked lists. Can you see if changing that to a far larger
value (twice the number of files you have) helps a little?
I don't know exactly why two-pass parsing was added, but mutt supports
doing inode sorting first which is supposed to result in far less disk
seeking in case of cache misses. Though disabled by default, mutt -v
should show if it's enabled or not.
I recall some people reporting that it even makes header cache performance
worse if enabled.
I did some quick checks on the code and to me there's no obvious change to
improve performance (besides better memory management, i.e. allocating
larger blocks at once, using bigger hash tables, etc). It basically does
readdir() as first pass, and parses all messages not in the cache as
second.
--
Ticket URL: <http://dev.mutt.org/trac/ticket/2981#comment:1>