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