From: Vladimir Marek Date: Thu, 29 Aug 2013 19:41:14 +0000 (+0200) Subject: Re: Re: Possible addtions to notmuch new ? X-Git-Url: http://git.tremily.us/?a=commitdiff_plain;h=574c1a9033dbd201e245a558d7c84a385de6823c;p=notmuch-archives.git Re: Re: Possible addtions to notmuch new ? --- diff --git a/76/2504ac0e0d584601c0d7a2d1831b288aa92dca b/76/2504ac0e0d584601c0d7a2d1831b288aa92dca new file mode 100644 index 000000000..9949a64d2 --- /dev/null +++ b/76/2504ac0e0d584601c0d7a2d1831b288aa92dca @@ -0,0 +1,112 @@ +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 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