Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id AD2B9431FD0 for ; Tue, 7 Dec 2010 17:19:16 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.99 X-Spam-Level: X-Spam-Status: No, score=-0.99 tagged_above=-999 required=5 tests=[ALL_TRUSTED=-1, T_MIME_NO_TEXT=0.01] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RVfhmv7nC4S; Tue, 7 Dec 2010 17:19:15 -0800 (PST) Received: from yoom.home.cworth.org (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id D5755431FB5; Tue, 7 Dec 2010 17:19:15 -0800 (PST) Received: by yoom.home.cworth.org (Postfix, from userid 1000) id 8505D2540E7; Tue, 7 Dec 2010 17:19:15 -0800 (PST) From: Carl Worth To: Austin Clements , notmuch@notmuchmail.org Subject: Re: [PATCH 3/4] Optimize thread search using matched docid sets. In-Reply-To: <20101117192826.GU2439@mit.edu> References: <20101117192826.GU2439@mit.edu> User-Agent: Notmuch/0.5 (http://notmuchmail.org) Emacs/23.2.1 (i486-pc-linux-gnu) Date: Tue, 07 Dec 2010 17:19:15 -0800 Message-ID: <874oap5aek.fsf@yoom.home.cworth.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 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: Wed, 08 Dec 2010 01:19:16 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable On Wed, 17 Nov 2010 14:28:26 -0500, Austin Clements wrot= e: > This reduces thread search's 1+2t Xapian queries (where t is the > number of matched threads) to 1+t queries and constructs exactly one > notmuch_message_t for each message instead of 2 to 3. Fantastic stuff, Austin! I've merged this now, (sorry it took me a while to get to it). One of the reasons I didn't merge it immediately is that I wanted to ensure that I understood the original author-ordering bug. Basically, I'm inherently uncomfortable with a performance optimization that fixes a bug as a side effect, (unless we understand that very well). So what I pushed actually adds the bug fix first, so that the performance optimization makes no change at all to the test suite. That feels better to me, (even though it simply demonstrated conclusively that the bug was in a piece of code that was eliminated by the optimization). Anyway, in a quick reading of the code, the only little thing I saw was: > + size_t count =3D (bound + sizeof (doc_ids->bitmap[0]) - 1) / > + sizeof (doc_ids->bitmap[0]); Which would look better to my eyes with a 1 factored out of the division: size_t count =3D 1 + (bound - 1) / sizeof (doc_ids->bitmap[0]); And the repeated use of "sizeof (doc_ids->bitmap[0])" could maybe do with a macro for better legibility. Though it would be an evil macro if it didn't accept an argument, and it wouldn't be much shorter if it did. So maybe it's fine as-is. Thanks for the optimization. Now all we need is a little notmuch benchmark so that I can be sure not to regress any performance work with my sloppy coding! =2DCarl =2D-=20 carl.d.worth@intel.com --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFM/t0T6JDdNq8qSWgRAuU/AJ9pvhXKE4G8+0JEf0FVXYfxXnYs5QCfa+13 v6A7ICXrxwg6XGfHLL6M0Zo= =Gwm5 -----END PGP SIGNATURE----- --=-=-=--