Read mail directory in inode number order
authorStewart Smith <stewart@flamingspork.com>
Wed, 18 Nov 2009 01:56:40 +0000 (12:56 +1100)
committerCarl Worth <cworth@cworth.org>
Wed, 18 Nov 2009 21:25:41 +0000 (22:25 +0100)
commita45ff8c36112a2f17c1ad5c20a16c30a47759797
tree09446bb902dbeefc49b215f03f4a58aa806d5c81
parent0656fb518df3190aebc04ed955c8b3c3cc21759c
Read mail directory in inode number order

This gives a rather decent reduction in number of seeks required when
reading a Maildir that isn't in pagecache.

Most filesystems give some locality on disk based on inode numbers.
In ext[234] this is the inode tables, in XFS groups of sequential inode
numbers are together on disk and the most significant bits indicate
allocation group (i.e inode 1,000,000 is always after inode 1,000).

With this patch, we read in the whole directory, sort by inode number
before stat()ing the contents.

Ideally, directory is sequential and then we make one scan through the
file system stat()ing.

Since the universe is not ideal, we'll probably seek during reading the
directory and a fair bit while reading the inodes themselves.

However... with readahead, and stat()ing in inode order, we should be
in the best place possible to hit the cache.

In a (not very good) benchmark of "how long does it take to find the first
15,000 messages in my Maildir after 'echo 3 > /proc/sys/vm/drop_caches'",
this patch consistently cut at least 8 seconds off the scan time.

Without patch: 50 seconds
With patch: 38-42 seconds.

(I did this in a previous maildir reading project and saw large improvements too)
notmuch-new.c