Re: [PATCH] emacs: Use a single buffer invisibility spec to fix quadratic search...
authorPieter Praet <pieter@praet.org>
Tue, 15 Nov 2011 16:45:10 +0000 (17:45 +0100)
committerW. Trevor King <wking@tremily.us>
Fri, 7 Nov 2014 17:40:11 +0000 (09:40 -0800)
cf/06f6b82775ef5fce4f212ae68864ccbae0605e [new file with mode: 0644]

diff --git a/cf/06f6b82775ef5fce4f212ae68864ccbae0605e b/cf/06f6b82775ef5fce4f212ae68864ccbae0605e
new file mode 100644 (file)
index 0000000..a43af55
--- /dev/null
@@ -0,0 +1,144 @@
+Return-Path: <pieter@praet.org>\r
+X-Original-To: notmuch@notmuchmail.org\r
+Delivered-To: notmuch@notmuchmail.org\r
+Received: from localhost (localhost [127.0.0.1])\r
+       by olra.theworths.org (Postfix) with ESMTP id 8AC9E429E21\r
+       for <notmuch@notmuchmail.org>; Tue, 15 Nov 2011 08:46:15 -0800 (PST)\r
+X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
+X-Spam-Flag: NO\r
+X-Spam-Score: -0.7\r
+X-Spam-Level: \r
+X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5\r
+       tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
+Received: from olra.theworths.org ([127.0.0.1])\r
+       by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
+       with ESMTP id ztKYTNr6+rCy for <notmuch@notmuchmail.org>;\r
+       Tue, 15 Nov 2011 08:46:11 -0800 (PST)\r
+Received: from mail-ww0-f45.google.com (mail-ww0-f45.google.com\r
+ [74.125.82.45])       (using TLSv1 with cipher RC4-SHA (128/128 bits))        (No client\r
+ certificate requested)        by olra.theworths.org (Postfix) with ESMTPS id\r
+ E2D42431FB6   for <notmuch@notmuchmail.org>; Tue, 15 Nov 2011 08:46:10 -0800\r
+ (PST)\r
+Received: by wwf10 with SMTP id 10so6201379wwf.2\r
+       for <notmuch@notmuchmail.org>; Tue, 15 Nov 2011 08:46:09 -0800 (PST)\r
+Received: by 10.181.12.39 with SMTP id en7mr30989268wid.40.1321375568962;\r
+       Tue, 15 Nov 2011 08:46:08 -0800 (PST)\r
+Received: from localhost ([109.131.148.49])\r
+       by mx.google.com with ESMTPS id i8sm14689564wie.11.2011.11.15.08.46.07\r
+       (version=TLSv1/SSLv3 cipher=OTHER);\r
+       Tue, 15 Nov 2011 08:46:07 -0800 (PST)\r
+From: Pieter Praet <pieter@praet.org>\r
+To: Austin Clements <amdragon@MIT.EDU>\r
+Subject: Re: [PATCH] emacs: Use a single buffer invisibility spec to fix\r
+       quadratic search cost.\r
+In-Reply-To: <20111111045341.GS2658@mit.edu>\r
+References: <1320807328-13728-1-git-send-email-amdragon@mit.edu>\r
+       <877h382jax.fsf@SSpaeth.de>\r
+       <CAPFwwQgsqe2NE9vm2RJHHK+8hWR_uMWKLHcxm0xkjduFboAfPw@mail.gmail.com>\r
+       <87d3czxsu9.fsf@praet.org> <20111111045341.GS2658@mit.edu>\r
+User-Agent: Notmuch/0.9+76~g2fd88e6 (http://notmuchmail.org) Emacs/23.3.1\r
+       (x86_64-unknown-linux-gnu)\r
+Date: Tue, 15 Nov 2011 17:45:10 +0100\r
+Message-ID: <87fwhpjpwp.fsf@praet.org>\r
+MIME-Version: 1.0\r
+Content-Type: text/plain; charset=utf-8\r
+Content-Transfer-Encoding: quoted-printable\r
+Cc: notmuch@notmuchmail.org, servilio <servilio@gmail.com>\r
+X-BeenThere: notmuch@notmuchmail.org\r
+X-Mailman-Version: 2.1.13\r
+Precedence: list\r
+List-Id: "Use and development of the notmuch mail system."\r
+       <notmuch.notmuchmail.org>\r
+List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
+List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
+List-Post: <mailto:notmuch@notmuchmail.org>\r
+List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
+List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
+       <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
+X-List-Received-Date: Tue, 15 Nov 2011 16:46:15 -0000\r
+\r
+On Thu, 10 Nov 2011 23:53:41 -0500, Austin Clements <amdragon@MIT.EDU> wrot=\r
+e:\r
+> Quoth Pieter Praet on Nov 11 at  4:04 am:\r
+> > On Thu, 10 Nov 2011 14:22:30 -0500, servilio <servilio@gmail.com> wrote:\r
+> > > On 10 November 2011 08:33, Sebastian Spaeth <Sebastian@sspaeth.de> wr=\r
+ote:\r
+> > > > On Tue, =C2=A08 Nov 2011 21:55:28 -0500, Austin Clements <amdragon@=\r
+MIT.EDU> wrote:\r
+> > > >> =C2=A0emacs/notmuch.el | =C2=A0 11 +++--------\r
+> > > >> =C2=A01 files changed, 3 insertions(+), 8 deletions(-)\r
+> > > >\r
+> > > >\r
+> > > > Tested and works great here! +1 for quick inclusion.\r
+> > >=20\r
+> > > I join the petition, I have been using for a couple of days and the\r
+> > > difference is noticeable.\r
+> > >=20\r
+> >=20\r
+> > Subjectively, I'm not seeing any difference, but that may be due to a\r
+> > relatively recent machine, and Austin's recent rebase [1] of Istvan's\r
+> > database patch [2] no doubt makes a huge difference as well.\r
+>=20\r
+> How many results?  Since it's eliminating a quadratic factor, this\r
+> only affects large search result buffers (and only once they grow\r
+> large; the beginning of the buffer will come in just as quickly with\r
+> or without this).\r
+>=20\r
+\r
+About the same as with my review [1] of the database patch [2], so ~9540.\r
+\r
+> > I've tried getting some hard numbers using\r
+> >=20\r
+> >   #+begin_src sh\r
+> >     time emacs --eval '(progn\r
+> >         (notmuch)\r
+> >         (notmuch-search "*")\r
+> >         (while (get-buffer-process (current-buffer))\r
+> >             (sleep-for 0.1))\r
+> >         (kill-emacs))'\r
+> >   #+end_src\r
+> >=20\r
+> > ... but the results vary wildly on subsequent runs.\r
+>=20\r
+> For me, this doesn't actually display the results buffer (though I\r
+> don't know why not), which means it won't test this, since the problem\r
+> lies in the Emacs redisplay logic.  However, I think it does yield a\r
+> baseline of how long it takes to construct the buffer without\r
+> displaying it.  This is interesting because, while this patch does not\r
+> achieve this baseline time, this patch combined with another one I\r
+> have waiting in the wings, does.\r
+>=20\r
+\r
+That's it!  I've been running the test unattended, so I failed to notice\r
+that the results buffer isn't always displayed (i.e. sometimes it is,\r
+causing the test to take quite a bit longer).\r
+\r
+> > How would one go about getting stable results?\r
+>=20\r
+> The results are quite stable for me, both timing it manually and using\r
+> the command you gave above.  The only non-obvious thing that comes to\r
+> mind is that you're probably testing on multiple cores, in which case\r
+> the kernel scheduler could introduce a lot of noise.  You could try\r
+> running numactl -C 0 emacs ... to see if there's any merit to this\r
+> theory.\r
+\r
+Hmm, numactl isn't available on my system;\r
+\r
+I seem to have only a single node @ '/sys/devices/system/node/', and\r
+both cpu0 and cpu1 @ '/sys/devices/system/cpu/' contain a symlink to\r
+'node0'.\r
+\r
+I'm guessing my kernel lacks support for NUMA policy?\r
+\r
+Either way, this works:\r
+  echo 0 > /sys/devices/system/cpu/cpu1/online\r
+\r
+\r
+Peace\r
+\r
+--=20\r
+Pieter\r
+\r
+[1] id:"87obwjtpcd.fsf@praet.org"\r
+[2] id:"1320599856-24078-1-git-send-email-amdragon@mit.edu"\r