* Looking for help re: inbox/thread/tree slowdown; misconfiguration?
@ 2020-07-27 23:36 jonathan
2020-07-28 1:41 ` David Bremner
0 siblings, 1 reply; 4+ messages in thread
From: jonathan @ 2020-07-27 23:36 UTC (permalink / raw)
To: notmuch
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!
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Looking for help re: inbox/thread/tree slowdown; misconfiguration?
2020-07-27 23:36 Looking for help re: inbox/thread/tree slowdown; misconfiguration? jonathan
@ 2020-07-28 1:41 ` David Bremner
2020-07-28 11:07 ` David Bremner
0 siblings, 1 reply; 4+ messages in thread
From: David Bremner @ 2020-07-28 1:41 UTC (permalink / raw)
To: jonathan, notmuch
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?
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Looking for help re: inbox/thread/tree slowdown; misconfiguration?
2020-07-28 1:41 ` David Bremner
@ 2020-07-28 11:07 ` David Bremner
2020-07-28 13:46 ` Jonathan Wilner
0 siblings, 1 reply; 4+ messages in thread
From: David Bremner @ 2020-07-28 11:07 UTC (permalink / raw)
To: jonathan, notmuch; +Cc: David Edmondson, Mark Walters
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
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: Looking for help re: inbox/thread/tree slowdown; misconfiguration?
2020-07-28 11:07 ` David Bremner
@ 2020-07-28 13:46 ` Jonathan Wilner
0 siblings, 0 replies; 4+ messages in thread
From: Jonathan Wilner @ 2020-07-28 13:46 UTC (permalink / raw)
To: David Bremner, notmuch; +Cc: David Edmondson, Mark Walters
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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2020-07-28 13:46 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-27 23:36 Looking for help re: inbox/thread/tree slowdown; misconfiguration? jonathan
2020-07-28 1:41 ` David Bremner
2020-07-28 11:07 ` David Bremner
2020-07-28 13:46 ` Jonathan Wilner
Code repositories for project(s) associated with this public inbox
https://yhetil.org/notmuch.git/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).