search

pazz / alot

Terminal-based Mail User Agent
GNU General Public License v3.0
695 stars 164 forks source link

search_threads_rebuild_limit sane default #1518

Open ryneeverett opened 4 years ago

ryneeverett commented 4 years ago

Describe the bug The default search_threads_rebuild_limit introduced in #1499 is infinite which "can be very slow in searches that yield thousands of results".

I don't much care what the limit is but infinite can't be a reasonable default. Maybe 1000?

Software Versions

To Reproduce Steps to reproduce the behaviour:

  1. open search buffer
  2. open a thread
  3. untag the thread
  4. close the buffer
  5. refresh the search buffer
pazz commented 4 years ago

You're probably right but I wouldn't know what default to take. This very much depends on the setup and user preferences. For me, 1000 and infinite is the same as I have virtually no threads with more than 100 messages.

ryneeverett commented 4 years ago

This doesn't iterate over messages in a thread, it iterates over threads in a search buffer. While not an ideal situation, it's not uncommon to have thousands of emails in an inbox and this causes very long UI blocking.

ryneeverett commented 4 years ago

Another thought is that a subtle UI notification could let the user know why the UI is blocking and point them toward this setting. Folks with low amounts of email and/or fast enough processors might not even notice the notification.

ryneeverett commented 4 years ago

(I personally had to git bisect to figure out what the issue was.)

pazz commented 4 years ago

Yes, these are great suggestions! P

meskio commented 4 years ago

I see the same problem here, some search take really long to display. I think is even more serious having a lot of encrypted email, it does try to decrypt it to display the search buffer, and decrypting email is not always fast.

Setting up search_threads_rebuild_limit to 100 seems to improve the situation alot.

Thanks @ryneeverett to start the work on that.

meskio commented 4 years ago

I was wrong, the thing that improved the situation for me was to remove the hook I use to auto-refresh every buffer I switch to.

Refreshing keeps being pretty slow, even with search_threads_rebuild_limit set to 1. I'm trying to figure out where this slowness comes from. But I amazed how notmuch search tag:unread takes 0.02s but doing the same search in alot right now takes 100 times that.

meskio commented 4 years ago

I found out the source of my slowness. If I set thread_authors_replace_me to False it gets fast again. It looks like doing this author replacement does read from disk every email in the search query, mostly if there emails are encrypted this takes a while to load. This config flag seems to be around since a while, I'm not sure why I'm noticing this slowness now.

Anyway I guess my problem is not related to the topic of this issue, sorry for the noise here. I opened an issue for it #1520