Date: Thu, 10 Nov 2011 23:53:41 -0500
From: Austin Clements <amdragon@MIT.EDU>
To: Pieter Praet <pieter@praet.org>
Subject: Re: [PATCH] emacs: Use a single buffer invisibility spec to fix
	quadratic search cost.
Message-ID: <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <87d3czxsu9.fsf@praet.org>
User-Agent: Mutt/1.5.21 (2010-09-15)
Cc: notmuch@notmuchmail.org, servilio <servilio@gmail.com>
Precedence: list

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.