On Mon, Dec 17, 2018 at 07:59 Tristan Cacqueray wrote: > Hi, > > I have been testing emacs as a mail client recently, so first, thank you for > all the work on notmuch and the emacs mode, it's really neat :) > > My main issue is that, while notmuch-search is super fast to show the first > messages, it seems like it is processing the whole query output in the > background, which is resulting in a long cpu load for large search... > > Reading through the notmuch.el code, it seems like the search process output > is ingested by a scratch buffer, and iiuc we can't control how fast the stdout > gets processed. I tried adding some delay on the process-filter but that > doesn't seems to work. > > I'm pretty much a lisp beginer, thus I don't know how doable this is, but > can we replace that scratch buffer or the make-process usage by something > that enables stdout's reading to be controled based on the window status > (e.g. only read more when the window reaches the end of the buffer) ? > > As an alternative solution, I've looked into sending STOP and CONT signal to > the process using the patch below. It's a bit buggy when changing windows, > and it assumes the active window is the one being scrolled, but it does > make the notmuch-search window reads and parses the message when needed... > > What would be the best way to improve notmuch-search efficiency? > (beside adding search limit to the queries...) > Hi, Here is a quick follow-up from the irc discussions. The SIGSTOP trick doesn't work well with ssh wrapper, because the signal doesn't propagate to the remote process with the standard ssh client. Moreover, resuming a search after a db update may not work too. However this works well for me, and below is an improved implementation as other may find it useful. Alternative solutions are: - the query limit patch[0], but extending reload the whole search, - use pagination, but this needs a get_msgs() patch. Thank you all for the suggestions. -Tristan [0]: https://notmuchmail.org/pipermail/notmuch/2011/006297.html