Re: Re: Possible addtions to notmuch new ?

[Vladimir Marek <Vladimir.Marek@Oracle.COM>]

> > 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