ee/96bef278bd75d55cddadc6d00d420eda84552c

   1 Return-Path: <sascha-ml-email-notmuch-notmuch@silbe.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 0AAB6431FB6\r
   6         for <notmuch@notmuchmail.org>; Mon, 25 Jun 2012 15:14:20 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: 0\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
  12         autolearn=disabled\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id qfDweLdEfyDB for <notmuch@notmuchmail.org>;\r
  16         Mon, 25 Jun 2012 15:14:19 -0700 (PDT)\r
  17 Received: from smtp.chost.de (setoy.chost.de [217.160.209.225])\r
  18         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  19         (No client certificate requested)\r
  20         by olra.theworths.org (Postfix) with ESMTPS id CAFBA431FAF\r
  21         for <notmuch@notmuchmail.org>; Mon, 25 Jun 2012 15:14:18 -0700 (PDT)\r
  22 Received: (qmail 13902 invoked by uid 5015); 25 Jun 2012 22:14:16 -0000\r
  23 Received: (nullmailer pid 27762 invoked by uid 123);\r
  24         Mon, 25 Jun 2012 22:14:16 -0000\r
  25 Received: from twin.sascha.silbe.org (twin.sascha.silbe.org [192.168.1.2])\r
  26         by flatty.sascha.silbe.org ([192.168.1.252])\r
  27         with SMTP via TCP; 25 Jun 2012 22:14:16 -0000\r
  28 Received: (nullmailer pid 3812 invoked by uid 8193);\r
  29         Mon, 25 Jun 2012 22:14:16 -0000\r
  30 To: Austin Clements <amdragon@MIT.EDU>, notmuch <notmuch@notmuchmail.org>\r
  31 Subject: Re: [PATCH 0/3] Speed up notmuch new for unchanged directories\r
  32 In-Reply-To: <87pq8n1de4.fsf@awakening.csail.mit.edu>\r
  33 References: <1340555366-25891-1-git-send-email-sascha-pgp@silbe.org>\r
  34         <87pq8n1de4.fsf@awakening.csail.mit.edu>\r
  35 User-Agent: Notmuch/0.13.2+51~gecf7cfe (http://notmuchmail.org) Emacs/23.2.1\r
  36         (x86_64-pc-linux-gnu)\r
  37 Date: Tue, 26 Jun 2012 00:13:40 +0200\r
  38 Message-ID: <toed34nyr8r.fsf@twin.sascha.silbe.org>\r
  39 MIME-Version: 1.0\r
  40 Content-Type: multipart/signed; boundary="=-=-=";\r
  41         micalg=pgp-sha512; protocol="application/pgp-signature"\r
  42 From: Sascha Silbe <sascha-ml-reply-to-2012-3@silbe.org>\r
  43 X-BeenThere: notmuch@notmuchmail.org\r
  44 X-Mailman-Version: 2.1.13\r
  45 Precedence: list\r
  46 List-Id: "Use and development of the notmuch mail system."\r
  47         <notmuch.notmuchmail.org>\r
  48 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  49         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  50 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  51 List-Post: <mailto:notmuch@notmuchmail.org>\r
  52 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  53 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  54         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  55 X-List-Received-Date: Mon, 25 Jun 2012 22:14:20 -0000\r
  56 \r
  57 --=-=-=\r
  58 Content-Type: text/plain; charset=utf-8\r
  59 Content-Transfer-Encoding: quoted-printable\r
  60 \r
  61 Austin Clements <amdragon@MIT.EDU> writes:\r
  62 \r
  63 > On Sun, 24 Jun 2012, Sascha Silbe <sascha-pgp@silbe.org> wrote:\r
  64 \r
  65 ["notmuch new" listing every directory, even if it's unchanged]\r
  66 > I haven't looked over your patches yet, but this result surprises me.\r
  67 > Could you explain your setup a little more?  How much mail do you have\r
  68 > and across how many directories?  What file system are you using?\r
  69 \r
  70 As mentioned in passing already, I have a total of about 900k unique\r
  71 mails (sometimes several copies of them, received over different paths,\r
  72 e.g. mailing list and a direct CC). Most of that is "old" mails, in\r
  73 directories that are not getting updated. If notmuch would support mbox,\r
  74 I'd use that instead for those old mails. The total number of\r
  75 directories in the mail store is about 29k and the total number of files\r
  76 (including the git repository and mbox files that sup used) is about\r
  77 1.25M.\r
  78 \r
  79 Since a housekeeping job last weekend, the number of mails in\r
  80 directories that are still getting updated is about 4k, i.e. about 5=E2=80=\r
  81 =B0 of\r
  82 the total number of mails or 3=E2=80=B0 of the total number of files. The n=\r
  83 umber\r
  84 of directories getting updated is 104, i.e. about 4=E2=80=B0 of the total n=\r
  85 umber\r
  86 of directories.\r
  87 \r
  88 Ideally, we'd get the run-time of "notmuch new" down by a similar\r
  89 factor. With just plain POSIX and no additional information that won't\r
  90 be possible, but providing a way to channel information about updates\r
  91 into notmuch (rather than having it scan everything over and over again)\r
  92 should help. That information is already available as output from the\r
  93 mail fetching process (rsync in my case). Of course, it would be purely\r
  94 optional: "notmuch new" without additional information would simply\r
  95 continue to scan everything.\r
  96 \r
  97 \r
  98 > I'm also surprised that your new approach helps.  This directory listing\r
  99 > has to be read off disk one way or the other, but listing directories is\r
 100 > the bread-and-butter of file systems, whereas I would think that Xapian\r
 101 > would require more IO to accomplish the same effect.\r
 102 \r
 103 "notmuch new" needs to iterate over a list of all directories to find\r
 104 those with new mails (and potentially new subdirectories). However, it\r
 105 does not need to list the *contents* of those folders. I'm surprised as\r
 106 well, but rather in the opposite direction: Based on a naive\r
 107 calculation, we'd expect to see a speedup on the order of\r
 108 (1.25M+29k)/29k=C2=A0=3D=C2=A044. The actual results suggest that stat()ing=\r
 109  (done\r
 110 29k times both before and after the patch) is taking about 19 times as\r
 111 long as listing a directory entry (before the patch we listed 1M\r
 112 entries, now we list none if nothing has changed). (*)\r
 113 \r
 114 In practice, the speedup achieved by my patch is larger than what the\r
 115 benchmark suggests because there are other processes running that use\r
 116 RAM. If we need to read a lot from disk (like "notmuch new" did before\r
 117 my patch), there's a good chance it's already been evicted from the\r
 118 cache since the last run. The fewer we need to read, the more likely it\r
 119 is to still be in the cache. Similarly, reading lots of data from disk\r
 120 will displace other data in the cache. These effects are not covered by\r
 121 the pure "hot cache" and "cold cache" timings.\r
 122 \r
 123 \r
 124 > Does your patch win because you can specifically list subdirectories\r
 125 > out of Xapian, making the IO proportional to the number of\r
 126 > subdirectories instead of the number of subdirectories and files (even\r
 127 > though the constant factors probably favor reading from the file\r
 128 > system)?\r
 129 \r
 130 It wins because the factor is the number of files in each directory, not\r
 131 just some low constant based on file system overhead vs. Xapian\r
 132 overhead.\r
 133 \r
 134 \r
 135 > I like the idea of these patches, I just want to make sure I have a firm\r
 136 > grip on what's being optimized and why it wins.\r
 137 \r
 138 Certainly a good idea. Thanks for taking the time!\r
 139 \r
 140 Sascha\r
 141 \r
 142 (*) float(linsolve([29000*x + 1250000*y =3D 3.3 * 29000*x], [x])); in\r
 143     maxima, if you'd like to check the math.\r
 144 =2D-=20\r
 145 http://sascha.silbe.org/\r
 146 http://www.infra-silbe.de/\r
 147 \r
 148 --=-=-=\r
 149 Content-Type: application/pgp-signature\r
 150 \r
 151 -----BEGIN PGP SIGNATURE-----\r
 152 Version: GnuPG v1.4.10 (GNU/Linux)\r
 153 \r
 154 iQEcBAEBCgAGBQJP6OKVAAoJELpz82VMF3DaMzIIALpqmnz26Mk8EZMooszj6oOK\r
 155 rA6b+LO+B9qCdpSc1/0bs/qm7pC1AEs3G6ycliqntUddj34vq0jXW+yZ2llou6kk\r
 156 W56B4fVnamYX+AtFSrNHi9GxRcyDRK6fmZv5Qtr55poJayKFaeJNhaj4EblULtCp\r
 157 3JeEQI+x9FJglVMMp67QTZMlrn0JIxqyfeWDhbpBYdunJrraOtF3hmJeqfJbIcMm\r
 158 5rDkvwcvybjjP1oA5wHN/H8euoFb0CO0K+Y36MCiemu0xnijlGaUVt6/I/wjNn1F\r
 159 yesV4CQHZ5VsBKWYeLxV3BRETUDKvN5ds/gjffbZhoiJSShA/hCbYHPhj7jjdUc=\r
 160 =8WVY\r
 161 -----END PGP SIGNATURE-----\r
 162 --=-=-=--\r