GNU bug report logs - #58950
[PATCH] * lisp/subr.el (buffer-match-p): Optimise performance

Previous Next

Full log

Message #40 received at 58950 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dgutov <at> yandex.ru>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Mattias Engdegård <mattiase <at> acm.org>,
 Philip Kaludercic <philipk <at> posteo.net>, 58950 <at> debbugs.gnu.org
Subject: Re: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise
 performance
Date: Thu, 5 Jan 2023 15:01:17 +0200

On 05/01/2023 06:31, Stefan Monnier via Bug reports for GNU Emacs, the 
Swiss army knife of text editors wrote:
>>>> I'd like to let our language-level specialists to take the deeper look.
> Do we have any reason to believe that the performance of
> `buffer-match-p` is a problem in `display-buffer-alist`?
> 
> The benchmark you quote seems to be fairly different from what
> `display-buffer` does.  I'm not surprised your optimization improves
> this benchmark, but I'm wondering whether this use-case corresponds to
> a real life situation (and if so which).

I was also wondering that.

>>>> On the last note, I'm curious how many buffers would it take to see a
>>>> 50ms improvement in match-buffers' runtime when using the current
>>>> project-kill-buffer-conditions's value, for example.
> Also, where is `match-buffers` used?  I only see it used in
> `lisp/net/rcirc.el` in a way that can trivially be replaced with
> something much more efficient.

I suppose it could replace the use of dolist+project--buffer-check 
inside project--buffers-to-kill. But the main target of the patch under 
discussion is buffer-match-p, of course.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.