all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dgutov@yandex.ru>
To: Philip Kaludercic <philipk@posteo.net>, 58950@debbugs.gnu.org
Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance
Date: Mon, 7 Nov 2022 03:04:35 +0200	[thread overview]
Message-ID: <c08e7175-aa5c-0c46-7dc0-9be2658cd711@yandex.ru> (raw)
In-Reply-To: <875yfyebi0.fsf@posteo.net>

On 01.11.2022 21:11, Philip Kaludercic wrote:
> 1. Style.  I wrap the defun in a let (or rather letrec) block to avoid
>     littering the global namespace.  It isn't necessary, and one could
>     argue it makes debugging more difficult.
> 
> 2. Caching policy.  Caching is critical to this optimisation.  Just
>     using byte-compilation would cause the above test to slow down to
>     (76.323692627 656 57.088315405).  The question is if the hash map
>     will collect too much garbage over time, and if there is a better
>     approach that could be taken?

I'd like to let our language-level specialists to take the deeper look.

This approach looks the most straightforward, but there could be others, 
just like "compiling" the form inside defcustom setter (for 
project-kill-buffer-conditions, and every similar option), doing 
precompilation closer to where the rules are used (similar to 
font-lock-compile-keywords), or not doing any of that. All depending on 
how long a typical compilation takes, and how many buffers the user has 
to have, to see any noticeable benefit.

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.





  parent reply	other threads:[~2022-11-07  1:04 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-01 19:11 bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Philip Kaludercic
2022-11-04 23:00 ` Philip Kaludercic
2022-11-07  1:04 ` Dmitry Gutov [this message]
2022-12-31 13:56   ` Philip Kaludercic
2023-01-05  0:00     ` Dmitry Gutov
2023-01-05  4:31       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-05 10:31         ` Mattias Engdegård
2023-01-05 12:55           ` Dmitry Gutov
2023-01-06 11:17             ` Mattias Engdegård
2023-01-06 21:41               ` Dmitry Gutov
2023-01-07 12:57                 ` Mattias Engdegård
2023-01-08 21:48                   ` Dmitry Gutov
2023-01-09  6:24                     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-01-05 13:01         ` Dmitry Gutov
2023-01-05  0:02     ` Dmitry Gutov
2023-01-05  6:32       ` Eli Zaretskii
2023-01-05 12:49         ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=c08e7175-aa5c-0c46-7dc0-9be2658cd711@yandex.ru \
    --to=dgutov@yandex.ru \
    --cc=58950@debbugs.gnu.org \
    --cc=philipk@posteo.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.