Quoth Pieter Praet on Nov 11 at 4:04 am: > On Thu, 10 Nov 2011 14:22:30 -0500, servilio <servilio@gmail.com> wrote: > > On 10 November 2011 08:33, Sebastian Spaeth <Sebastian@sspaeth.de> wrote: > > > On Tue, 8 Nov 2011 21:55:28 -0500, Austin Clements <amdragon@MIT.EDU> wrote: > > >> emacs/notmuch.el | 11 +++-------- > > >> 1 files changed, 3 insertions(+), 8 deletions(-) > > > > > > > > > Tested and works great here! +1 for quick inclusion. > > > > I join the petition, I have been using for a couple of days and the > > difference is noticeable. > > > > Subjectively, I'm not seeing any difference, but that may be due to a > relatively recent machine, and Austin's recent rebase [1] of Istvan's > database patch [2] no doubt makes a huge difference as well. How many results? Since it's eliminating a quadratic factor, this only affects large search result buffers (and only once they grow large; the beginning of the buffer will come in just as quickly with or without this). > I've tried getting some hard numbers using > > #+begin_src sh > time emacs --eval '(progn > (notmuch) > (notmuch-search "*") > (while (get-buffer-process (current-buffer)) > (sleep-for 0.1)) > (kill-emacs))' > #+end_src > > ... but the results vary wildly on subsequent runs. For me, this doesn't actually display the results buffer (though I don't know why not), which means it won't test this, since the problem lies in the Emacs redisplay logic. However, I think it does yield a baseline of how long it takes to construct the buffer without displaying it. This is interesting because, while this patch does not achieve this baseline time, this patch combined with another one I have waiting in the wings, does. > How would one go about getting stable results? The results are quite stable for me, both timing it manually and using the command you gave above. The only non-obvious thing that comes to mind is that you're probably testing on multiple cores, in which case the kernel scheduler could introduce a lot of noise. You could try running numactl -C 0 emacs ... to see if there's any merit to this theory.