From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 405EE431FBC for ; Wed, 25 Nov 2009 11:17:46 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org 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 Evl5Dm1guHW4 for ; Wed, 25 Nov 2009 11:17:45 -0800 (PST) Received: from cworth.org (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 47391431FAE for ; Wed, 25 Nov 2009 11:17:45 -0800 (PST) From: Carl Worth To: Notmuch list Date: Wed, 25 Nov 2009 11:17:31 -0800 Message-ID: <87aayatnw4.fsf@yoom.home.cworth.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" Subject: Search results now start appearing "instantly" X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.12 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, 25 Nov 2009 19:17:46 -0000 --=-=-= Here's a nice feature for any of you who have been suffering with "notmuch search" taking forever before it would complete, (such as when trying to display "notmuch search tag:inbox" with every message in your collection having the inbox tag). I've fixed the "notmuch search" command-line program to not do any of the "chunking" that it was doing before, but to instead stream results out as quickly as possible. So it takes maybe a second or two before the results start appearing, but then it's a steady stream from then on. I've also fixed the emacs interface to "notmuch search" which previously would wait until the command completed and would then do the processing it needs to on the buffer. The new implementation instead fires off "notmuch search" as an asynchronous process and filters the results as they come in. The net effect is that searches now appear instantly and you can just watch the scrollbar shrink as the results keep coming in, (and you can navigate and read messages as much as you'd like while results keep coming). It's working out fairly well, (but for one minor bug which is that you lose your current position when you refresh). And I hope people are happy with it. For some it might take notmuch from "interesting, but too slow to be usable" to "blisteringly fast, and where have you been all my life". The one thing that might still be undesirable is that the "notmuch search" process will still continue to burn CPU until all of the results are complete. We could probably take some clues from the user's actions to ameliorate this. It would be easy to suspend the search process when the user obviously isn't needing more results and then resume it later. Detecting what the user needs is a little tricky, but in some cases will be obvious, (such as the user switching away from the scroll buffer or the user viewing a tiny fraction of the search results and not scrolling through them). So please update to the latest code and let me know what you think. I'll be interested to hear if this helps people, and also to know if the CPU usage is a problem for anybody. And for the authors of the other interfaces, let us know when you've got similar support for streaming searches, (or if you didn't get this automatically as soon as "notmuch search" was fixed). -Carl --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux) iD8DBQFLDYLL6JDdNq8qSWgRAtzpAKCY5RmiFppeH4K3u0zDu8QlXhaEwQCfbYzP HTuBbVw5/8yUXhs+xEKEkFU= =c0rD -----END PGP SIGNATURE----- --=-=-=--