On Thu, 10 Nov 2011 23:53:41 -0500, Austin Clements <amdragon@MIT.EDU> wrote:
> 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).
> 

About the same as with my review [1] of the database patch [2], so ~9540.

> > 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.
> 

That's it!  I've been running the test unattended, so I failed to notice
that the results buffer isn't always displayed (i.e. sometimes it is,
causing the test to take quite a bit longer).

> > 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.

Hmm, numactl isn't available on my system;

I seem to have only a single node @ '/sys/devices/system/node/', and
both cpu0 and cpu1 @ '/sys/devices/system/cpu/' contain a symlink to
'node0'.

I'm guessing my kernel lacks support for NUMA policy?

Either way, this works:
  echo 0 > /sys/devices/system/cpu/cpu1/online


Peace

-- 
Pieter

[1] id:"87obwjtpcd.fsf@praet.org"
[2] id:"1320599856-24078-1-git-send-email-amdragon@mit.edu"