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 73636431FD2 for ; Sat, 31 Aug 2013 23:59:42 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_MED=-2.3, UNPARSEABLE_RELAY=0.001] 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 i60PTRgDCTRV for ; Sat, 31 Aug 2013 23:59:36 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 6250B41A56A for ; Thu, 29 Aug 2013 12:41:27 -0700 (PDT) Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r7TJfMAV010250 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Aug 2013 19:41:23 GMT Received: from userz7021.oracle.com (userz7021.oracle.com [156.151.31.85]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TJfLOs006806 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 29 Aug 2013 19:41:22 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by userz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r7TJfLjh007382; Thu, 29 Aug 2013 19:41:21 GMT Received: from virt.cz.oracle.com (/10.163.102.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 29 Aug 2013 12:41:20 -0700 Date: Thu, 29 Aug 2013 21:41:14 +0200 From: Vladimir Marek To: Austin Clements Subject: Re: Re: Possible addtions to notmuch new ? Message-ID: <20130829194114.GA133@virt.cz.oracle.com> References: <20130812093443.GB16684@virt.cz.oracle.com> <20130812143426.GA13257@mit.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20130812143426.GA13257@mit.edu> User-Agent: Mutt/ (2012-12-30) X-Source-IP: acsinet22.oracle.com [141.146.126.238] Cc: notmuch@notmuchmail.org 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: Sun, 01 Sep 2013 06:59:42 -0000 > > My mail setup is a directory containing several subdirectories each > > subdirectory corresponds to one real mail account I am using. Each mail > > account is synchronized differently - I am using offlineimap, fetchmeail > > or even synthetically created emails (I am writing very simple jabber<-> > > mail gate).Every now and then I am running 'notmuch new' to discover new > > emails and make them available in my MUA. > > > > That works pretty well, but has some disadvantages too > > - notmuch new takes very long time (30s) during which the notmuch > > database seems to be locked for any other updates from my MUA > > - notmuch new takes long time because it always processes my archive > > dir containing many files. That's mostly un-necessary as typically > > there's no new mail delivered > > Could you try this patch? It's basically untested other than passing > the test suite, though in principle the worst harm it could do is make > notmuch new miss new messages or think renames are deletions. If it > helps significantly with your performance problems, I'll clean it up > and add a test. > > diff --git a/notmuch-new.c b/notmuch-new.c > index faa33f1..196c5cb 100644 > --- a/notmuch-new.c > +++ b/notmuch-new.c > @@ -323,6 +323,9 @@ add_files (notmuch_database_t *notmuch, > } > db_mtime = directory ? notmuch_directory_get_mtime (directory) : 0; > > + if (directory && db_mtime == fs_mtime && st.st_nlink == 2) > + goto DONE; > + > /* If the database knows about this directory, then we sort based > * on strcmp to match the database sorting. Otherwise, we can do > * inode-based sorting for faster filesystem operation. */ I'm sorry for my late reply. It cuts the average time of 'notmuch new' from 25s to 0.2s . Which is a bit scary :) But understandable. I have the notmuch database on NFS mount which hopefully won't make any difference here. Thank you for the tip! -- Vlad