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 CAB706DE02B5 for ; Thu, 7 Apr 2016 17:41:11 -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 d0NHCWl4bYP8 for ; Thu, 7 Apr 2016 17:41:03 -0700 (PDT) Received: from fethera.tethera.net (fethera.tethera.net [198.245.60.197]) by arlo.cworth.org (Postfix) with ESMTPS id 8E0C16DE0134 for ; Thu, 7 Apr 2016 17:41:03 -0700 (PDT) Received: from remotemail by fethera.tethera.net with local (Exim 4.84) (envelope-from ) id 1aoKU2-00009Q-U5; Thu, 07 Apr 2016 20:41:10 -0400 Received: (nullmailer pid 28044 invoked by uid 1000); Fri, 08 Apr 2016 00:40:59 -0000 From: David Bremner To: notmuch@notmuchmail.org, xapian-discuss@lists.xapian.org Subject: Re: slowdown in notmuch perf suite with xapian 1.3.5 In-Reply-To: <20160407232537.GB29434@survex.com> References: <87twjd639d.fsf@zancas.localnet> <20160407232537.GB29434@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 21:40:59 -0300 Message-ID: <87h9fd53vo.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 00:41:11 -0000 Olly Betts writes: > > So the T00-new.sh numbers make sense - there's more work to do, and > we need to read existing positional data more to insert the new stuff, > so the increased reads and writes make sense. > > But guessing at what the other two tests do, I wouldn't expect them to > be affected by this. The non-optimized-away cases of T02-tag just adding and deleting terms to each document with term Tmail > I'm also a bit puzzled by how glass can manage not to read any data > for "dump *", and several tests seem to not read or write anything > for either backend. What exactly are the "In/Out" numbers? that's just the output from /usr/bin/time -f '%e\t%U\t%S\t%M\t%I/%O' The manual describes them as "number of file system inputs/outputs". From looking at the source, they correspond to ru_inblock and ru_oublock fields from the getrusage call. AFAIU, that means the number of non-cached read/writes. d