alx/mu4e
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

* mu-index.1: updated manpage with some recent performance numbers

Browse Source
This commit is contained in:
Dirk-Jan C. Binnema
2010-11-28 13:40:36 +02:00
parent 7f0489575b
commit 9f43230160
1 changed files with 16 additions and 12 deletions
Download Patch File Download Diff File Expand all files Collapse all files

28
man/mu-index.1
View File

@ -20,7 +20,7 @@ then be searched using
understands Maildirs as defined by Daniel Bernstein for qmail(7). In addition,
it understands recursive Maildirs (Maildirs within Maildirs), Maildir++. It
can also deal with VFAT-based Maildirs which use '!' as the seperators instead
of ':' as used by Tinymail/Modest and some other e-mail programs.
of ':' as used by \fITinymail\fR/\fIModest\fR and some other e-mail programs.
E-mail messages which are not stored in something resembling a maildir leaf
directory (\fIcur\fR and \fInew\fR) are ignored.
@ -86,12 +86,12 @@ format. \fBmu index\fR will issue a warning about this.
\fB\-\-autoupgrade\fR automatically use \fB\-y\fR, \fB\-\-empty\fR
when \fBmu\fR notices that the database version is not up-to-date. This option
is for use in cron scripts and the like, so they won't require any user
interaction, even when mu introduces a new database vesion.
interaction, even when mu introduces a new database version.
.TP
.B NOTE:
It is probably not a good idea to run multiple instances of
It is not a good idea to run multiple instances of
.B mu index
concurrently. No data loss should occur, but one or more of the instances may
experience errors due to database locks.
@ -108,15 +108,15 @@ search parameter (see below).
.SS A note on performance
As a non-scientific benchmark, a simple test on the authors machine (a
Thinkpad X61s laptop using Linux 2.6.31 and an ext3 file system) with no
existing database, and a maildir with 14,200 messages:
Thinkpad X61s laptop using Linux 2.6.35 and an ext3 file system) with no
existing database, and a maildir with 27273 messages:
.nf
$ sudo sh -c 'sync && echo 3 > /proc/sys/vm/drop_caches'
$ time mu index --quiet
83.36s user 6.49s system 43% cpu 3:26.21 total
66,65s user 6,05s system 27% cpu 4:24,20 total
.si
(about 69 messages per second)
(about 103 messages per second)
A second run, which is the more typical use case when there is a database
already, goes much faster:
@ -124,9 +124,9 @@ already, goes much faster:
.nf
$ sudo sh -c 'sync && echo 3 > /proc/sys/vm/drop_caches'
$ time mu index --quiet
0.29s user 0.62s system 14% cpu 6.409 total
0,48s user 0,76s system 10% cpu 11,796 total
.si
(about 2219 message per second)
(more than 2300 messages per second)
Note that each of test flushes the caches first; a more common use case might
be to run \fBmu index\fR when new mail has arrived; the cache may stay
@ -134,10 +134,14 @@ quite 'warm' in that case:
.nf
$ time mu index --quiet
0.19s user 0.21s system 98% cpu 0.402 total
0,33s user 0,40s system 80% cpu 0,905 total
.si
which is more than 35,0000 messages per second (there is some variance here,
but the author has not seen it getting under 30,0000 messages per second).
which is more than 30000 messages per second.
In general, \fBmu\fR has been getting faster with each release, even with
relatively expensive new features such as text-normalization (for
case-insensitve/accent-insensitive matching). The profiles are dominated by
operations in the Xapian database now.
.SH FILES
By default, \fBmu index\fR stores its message database in \fI~/.mu/xapian\fR;