From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by arlo.cworth.org (Postfix) with ESMTP id 590F56DE02B5 for ; Thu, 7 Apr 2016 18:14:36 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at cworth.org X-Spam-Flag: NO X-Spam-Score: -0.02 X-Spam-Level: X-Spam-Status: No, score=-0.02 tagged_above=-999 required=5 tests=[AWL=-0.009, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=disabled Received: from arlo.cworth.org ([127.0.0.1]) by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW41mXuYw6UY for ; Thu, 7 Apr 2016 18:14:27 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 8E5E86DE0134 for ; Thu, 7 Apr 2016 18:14:26 -0700 (PDT) Received: from remotemail by fethera.tethera.net with local (Exim 4.84) (envelope-from ) id 1aoL0N-0000dI-M9; Thu, 07 Apr 2016 21:14:35 -0400 Received: (nullmailer pid 2722 invoked by uid 1000); Fri, 08 Apr 2016 01:14:24 -0000 From: David Bremner To: Olly Betts Cc: notmuch@notmuchmail.org, xapian-discuss@lists.xapian.org Subject: Re: slowdown in notmuch perf suite with xapian 1.3.5 In-Reply-To: <20160408005725.GA3037@survex.com> References: <87twjd639d.fsf@zancas.localnet> <20160407232537.GB29434@survex.com> <87h9fd53vo.fsf@zancas.localnet> <20160408005725.GA3037@survex.com> User-Agent: Notmuch/0.21+99~gd93d377 (http://notmuchmail.org) Emacs/24.5.1 (x86_64-pc-linux-gnu) Date: Thu, 07 Apr 2016 22:14:24 -0300 Message-ID: <87egag6gwf.fsf@zancas.localnet> MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Apr 2016 01:14:36 -0000 Olly Betts writes: > Non-cached reads/writes are arguably the most useful sort to measure, but the > reads at least will be sensitive to OS caching, which means a repeat run will > generally show lower numbers of reads, e.g.: > > $ /usr/bin/time -f '%I/%O' wc randomfile > 240 2908 96780 randomfile > 192/0 > $ /usr/bin/time -f '%I/%O' wc randomfile > 240 2908 96780 randomfile > 0/0 > > So those numbers may not be entirely comparable, depending what order your > tests were done in, and whether you'd run the tests (or cloned the repo or some > other operation which read or wrote the files used) recently enough that their > data might still be cached. Here are the number from second glass run. The order was glass / chert / glass T00-new.sh: Testing notmuch new [0.4 large] Wall(s) Usr(s) Sys(s) Res(K) In/Out(512B) Initial notmuch new 920.53 698.96 207.02 245188 3528/22442096 notmuch new #2 0.55 0.00 0.01 8048 6960/160 notmuch new #3 0.01 0.00 0.00 8112 0/8 notmuch new #4 0.01 0.01 0.00 8136 0/8 notmuch new #5 0.01 0.00 0.00 8140 0/8 notmuch new #6 0.01 0.00 0.00 8116 0/8 T01-dump-restore.sh: Testing dump and restore [0.4 large] Wall(s) Usr(s) Sys(s) Res(K) In/Out(512B) load nmbug tags 8.89 4.23 3.88 11648 368/40072 dump * 7.37 6.29 1.08 25268 72/27928 restore * 7.60 7.16 0.43 8624 0/0 T02-tag.sh: Testing tagging [0.4 large] Wall(s) Usr(s) Sys(s) Res(K) In/Out(512B) tag * +new_tag 474.16 274.89 191.52 34820 16/1920240 tag * +existing_tag 0.01 0.01 0.00 8480 152/0 tag * -existing_tag 438.62 239.02 195.44 34928 0/1970160 tag * -missing_tag 0.00 0.00 0.00 8264 0/0 It's a bit faster overall, but not radically so. So I think cache effects are not the main issue here.