From 9f432301603997da1179515787bce62505c9693d Mon Sep 17 00:00:00 2001
From: "Dirk-Jan C. Binnema" <djcb@djcbsoftware.nl>
Date: Sun, 28 Nov 2010 13:40:36 +0200
Subject: [PATCH] * mu-index.1: updated manpage with some recent performance
 numbers

---
 man/mu-index.1 | 28 ++++++++++++++++------------
 1 file changed, 16 insertions(+), 12 deletions(-)

diff --git a/man/mu-index.1 b/man/mu-index.1
index 9a8f5a49..5b5433c9 100644
--- a/man/mu-index.1
+++ b/man/mu-index.1
@@ -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;