From: Pieter Praet <pieter@praet.org>
To: Austin Clements <amdragon@MIT.EDU>
Subject: Re: [PATCH] emacs: Use a single buffer invisibility spec to fix
	quadratic search cost.
In-Reply-To: <20111111045341.GS2658@mit.edu>
References: <1320807328-13728-1-git-send-email-amdragon@mit.edu>
	<877h382jax.fsf@SSpaeth.de>
	<CAPFwwQgsqe2NE9vm2RJHHK+8hWR_uMWKLHcxm0xkjduFboAfPw@mail.gmail.com>
	<87d3czxsu9.fsf@praet.org> <20111111045341.GS2658@mit.edu>
User-Agent: Notmuch/0.9+76~g2fd88e6 (http://notmuchmail.org) Emacs/23.3.1
	(x86_64-unknown-linux-gnu)
Date: Tue, 15 Nov 2011 17:45:10 +0100
Message-ID: <87fwhpjpwp.fsf@praet.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Cc: notmuch@notmuchmail.org, servilio <servilio@gmail.com>
Precedence: list

On Thu, 10 Nov 2011 23:53:41 -0500, Austin Clements <amdragon@MIT.EDU> wrot=
e:
> 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> wr=
ote:
> > > > On Tue, =C2=A08 Nov 2011 21:55:28 -0500, Austin Clements <amdragon@=
MIT.EDU> wrote:
> > > >> =C2=A0emacs/notmuch.el | =C2=A0 11 +++--------
> > > >> =C2=A01 files changed, 3 insertions(+), 8 deletions(-)
> > > >
> > > >
> > > > Tested and works great here! +1 for quick inclusion.
> > >=20
> > > I join the petition, I have been using for a couple of days and the
> > > difference is noticeable.
> > >=20
> >=20
> > 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.
>=20
> 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).
>=20

About the same as with my review [1] of the database patch [2], so ~9540.

> > I've tried getting some hard numbers using
> >=20
> >   #+begin_src sh
> >     time emacs --eval '(progn
> >         (notmuch)
> >         (notmuch-search "*")
> >         (while (get-buffer-process (current-buffer))
> >             (sleep-for 0.1))
> >         (kill-emacs))'
> >   #+end_src
> >=20
> > ... but the results vary wildly on subsequent runs.
>=20
> 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.
>=20

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?
>=20
> 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

--=20
Pieter

[1] id:"87obwjtpcd.fsf@praet.org"
[2] id:"1320599856-24078-1-git-send-email-amdragon@mit.edu"