Looking for help re: inbox/thread/tree slowdown; misconfiguration?

Looking for help re: inbox/thread/tree slowdown; misconfiguration?

[jonathan]

Hi all,

I'm recently returning to notmuch after a few years of using mu4e. I'm thrilled to be back - the tag based workflow is fantastic!

However, I'm hitting a problem with tree-mode/threading that I can't seem to solve. I am hoping the folks on this list might have some suggestions.

I've got about 52K items with the tag "inbox". Should be "notmuch" right? :-)  Here's the problem - if I want to view that in tree view, it can take multiple minutes for
notmuch to return a result.

More critically, if I choose an item in the inbox that has even two messages in a thread-selecting it and wanting to see it in a tree appears to wind up with all messages
getting re-indexed. I can't see the two messages for a good 2-4 minutes, unless I kill the notmuch process that's running in the background. The process indicates that
notmuch is running through the whole inbox.

I accept that I am not doing a great job describing the bug (if it is one!) - but I am hoping someone on this list can minimally point me in right area to either provide
more debug info or how to optimize my config.

Thanks!

Re: Looking for help re: inbox/thread/tree slowdown; misconfiguration?

[David Bremner]

jonathan@teamwilner.com writes:

> I've got about 52K items with the tag "inbox". Should be "notmuch"
> right? :-) Here's the problem - if I want to view that in tree view,
> it can take multiple minutes for notmuch to return a result.

In general there should be some results right away, with the rest of the
buffer being filled asynchronously. Unfortunately notmuch-emacs only
handles the one asynchronous query, so if there is already a long
running query, you will indeed have to wait for the whole tree/list of
headers to be read into emacs.


> More critically, if I choose an item in the inbox that has even two
> messages in a thread-selecting it and wanting to see it in a tree
> appears to wind up with all messages getting re-indexed. I can't see
> the two messages for a good 2-4 minutes, unless I kill the notmuch
> process that's running in the background. The process indicates that
> notmuch is running through the whole inbox.

Hmm. I can't completely follow this. Are you talking about using Z from
notmuch-show-mode, or something else?

Re: Looking for help re: inbox/thread/tree slowdown; misconfiguration?

[David Bremner]

David Bremner <david@tethera.net> writes:

> jonathan@teamwilner.com writes:
>
>> I've got about 52K items with the tag "inbox". Should be "notmuch"
>> right? :-) Here's the problem - if I want to view that in tree view,
>> it can take multiple minutes for notmuch to return a result.
>
> In general there should be some results right away, with the rest of the
> buffer being filled asynchronously. Unfortunately notmuch-emacs only
> handles the one asynchronous query, so if there is already a long
> running query, you will indeed have to wait for the whole tree/list of
> headers to be read into emacs.
>

I think I see what is probably going on for you. You are probably first
opening the query with notmuch-search-mode, then switching to
notmuch-tree mode, This leads to the original query running in the
background, blocking your second (tree-mode) query from running. I
suggest trying M-x notmuch-tree directly (say in a fresh Emacs instance)
and see if it has the same delay.  If it works better, you can set the
default mode to open a saved search by customizing
notmuch-saved-searches.

It's been a while since I looked at the async code, maybe David E or
Mark have some ideas about how hard it would be to improve the current
behaviour of one async query blocking all others.

d

Re: Looking for help re: inbox/thread/tree slowdown; misconfiguration?

[Jonathan Wilner]

Thanks, David! I'm giving this a try now. So far, so good!

Best,

Jonathan 
David Bremner <david@tethera.net> writes:

> David Bremner <david@tethera.net> writes:
>
>> jonathan@teamwilner.com writes:
>>
>>> I've got about 52K items with the tag "inbox". Should be "notmuch"
>>> right? :-) Here's the problem - if I want to view that in tree view,
>>> it can take multiple minutes for notmuch to return a result.
>>
>> In general there should be some results right away, with the rest of the
>> buffer being filled asynchronously. Unfortunately notmuch-emacs only
>> handles the one asynchronous query, so if there is already a long
>> running query, you will indeed have to wait for the whole tree/list of
>> headers to be read into emacs.
>>
>
> I think I see what is probably going on for you. You are probably first
> opening the query with notmuch-search-mode, then switching to
> notmuch-tree mode, This leads to the original query running in the
> background, blocking your second (tree-mode) query from running. I
> suggest trying M-x notmuch-tree directly (say in a fresh Emacs instance)
> and see if it has the same delay.  If it works better, you can set the
> default mode to open a saved search by customizing
> notmuch-saved-searches.
>
> It's been a while since I looked at the async code, maybe David E or
> Mark have some ideas about how hard it would be to improve the current
> behaviour of one async query blocking all others.
>
> d