From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 01 Nov 2022 19:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 58950@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.166732987727196 (code B ref -1); Tue, 01 Nov 2022 19:12:02 +0000 Received: (at submit) by debbugs.gnu.org; 1 Nov 2022 19:11:17 +0000 Received: from localhost ([127.0.0.1]:44250 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opwfI-00074W-V9 for submit@debbugs.gnu.org; Tue, 01 Nov 2022 15:11:17 -0400 Received: from lists.gnu.org ([209.51.188.17]:59336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1opwfG-00074O-RO for submit@debbugs.gnu.org; Tue, 01 Nov 2022 15:11:11 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1opwfG-0005il-Jy for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 15:11:10 -0400 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1opwfD-0000AZ-8s for bug-gnu-emacs@gnu.org; Tue, 01 Nov 2022 15:11:10 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id D189A240103 for ; Tue, 1 Nov 2022 20:11:04 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667329864; bh=X3hp3DOimqNA/sHJyFisRQo6gxIdDOOkG9TsQbnfutY=; h=From:To:Subject:Autocrypt:Date:From; b=QxhFbslYDteLXfV1DEw7k/qzVNyckFS9JRKAA4zRQ1lemsvdzPNsCXBXreaQivC1b bHkDrgh4qvTjW1hIsGDV/ia4OmriMP9ytfDtxqvic95668G5PkQoBv2nf7S7gqRCLb +oMH3Qv5bOV8Pkb4BBk6oOJaYrnp0qDEQr3ZBoyDXHyyg99pRbTaBaywVTxSheblTJ l5fpkBAtWbstp1gynXpnE7KIGPFWtjRFlVnp3uqQmsvxi70y891laqRCfMYq+hSsGs vVUODiCfwLRoXaGsxxha2e7zrryWLpZ7YzNEt6YaBJZEsU79c5FNBKLjHfKMDTHkkZ gCzDsIyufKVMw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N203r1jXYz6tmL for ; Tue, 1 Nov 2022 20:11:03 +0100 (CET) From: Philip Kaludercic Autocrypt: addr=philipk@posteo.net; prefer-encrypt=nopreference; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB Date: Tue, 01 Nov 2022 19:11:03 +0000 Message-ID: <875yfyebi0.fsf@posteo.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Received-SPF: pass client-ip=185.67.36.66; envelope-from=philipk@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Tags: patch The below patch is based on a tangent discussion in bug#58839, the below patch was written in collaboration with Jo=C3=A3o T=C3=A1vora. It involves= an optimisation to `buffer-match-p' that dramatically speeds the execution of the function. This is important for the very least as `buffer-match-p' is used for displaying buffer. Running (benchmark-run 1000 (match-buffers "\\*.+\\*")) I previously got (22.822269875 178 15.524474267999977), and with the patch applied (0.27100275 2 0.1730835160000197). There are a few points that can be discussed: 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? In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version 3.24.30, cairo version 1.16.0) of 2022-10-31 built on heron Repository revision: 462a66e79edcc34ecbeef7cc1604765adfdc038e Repository branch: feature/package+vc System Description: Guix System Configured using: 'configure --with-pgtk --with-imagemagick PKG_CONFIG_PATH=3D/gnu/store/ssg343s6ldqdwh30136pnawhbgd0cb6i-profile/lib/= pkgconfig:/gnu/store/ssg343s6ldqdwh30136pnawhbgd0cb6i-profile/share/pkgconf= ig' --=-=-= Content-Type: text/patch Content-Disposition: attachment; filename=0002-lisp-subr.el-buffer-match-p-Accelerate-using-byte-co.patch >From 0a9ddbcc6958fa7ed94456722a3eee65582a56b2 Mon Sep 17 00:00:00 2001 From: Philip Kaludercic Date: Tue, 1 Nov 2022 19:57:49 +0100 Subject: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance --- lisp/subr.el | 75 +++++++++++++++++++++++++++------------------------- 1 file changed, 39 insertions(+), 36 deletions(-) diff --git a/lisp/subr.el b/lisp/subr.el index 83e2e75c41..0dd7a814d9 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -7002,8 +7002,38 @@ string-lines (setq start (length string))))) (nreverse lines)))) -(defun buffer-match-p (condition buffer-or-name &optional arg) - "Return non-nil if BUFFER-OR-NAME matches CONDITION. +(letrec ((buffer-sym (make-symbol "buffer")) + (arg-sym (make-symbol "arg")) + (translate + (lambda (condition) + "Compile a CONDITION into a predicate function." + (pcase-exhaustive condition + ((or 't 'nil) + condition) + ((pred stringp) + `(string-match-p ,condition (buffer-name ,buffer-sym))) + ((pred functionp) + (if (eq 1 (cdr (func-arity condition))) + `(condition ,buffer-sym) + `(condition + ,buffer-sym + ,arg-sym))) + (`(major-mode . ,mode) + `(eq (buffer-local-value 'major-mode ,buffer-sym) + ',mode)) + (`(derived-mode . ,mode) + `(provided-mode-derived-p + (buffer-local-value 'major-mode ,buffer-sym) + ',mode)) + (`(not . ,cond) + `(not ,(funcall translate cond))) + (`(or . ,conds) + `(or ,@(mapcar translate conds))) + (`(and . ,conds) + `(and ,@(mapcar translate conds)))))) + (cond-cache (make-hash-table :test 'eq))) + (defun buffer-match-p (condition buffer-or-name &optional arg) + "Return non-nil if BUFFER-OR-NAME matches CONDITION. CONDITION is either: - the symbol t, to always match, - the symbol nil, which never matches, @@ -7022,40 +7052,13 @@ buffer-match-p to be met. * `or': the cdr is a list of recursive condition, of which at least one has to be met." - (letrec - ((buffer (get-buffer buffer-or-name)) - (match - (lambda (conditions) - (catch 'match - (dolist (condition conditions) - (when (pcase condition - ('t t) - ((pred stringp) - (string-match-p condition (buffer-name buffer))) - ((pred functionp) - (if (eq 1 (cdr (func-arity condition))) - (funcall condition buffer) - (funcall condition buffer arg))) - (`(major-mode . ,mode) - (eq - (buffer-local-value 'major-mode buffer) - mode)) - (`(derived-mode . ,mode) - (provided-mode-derived-p - (buffer-local-value 'major-mode buffer) - mode)) - (`(not . ,cond) - (not (funcall match cond))) - (`(or . ,args) - (funcall match args)) - (`(and . ,args) - (catch 'fail - (dolist (c args) - (unless (funcall match (list c)) - (throw 'fail nil))) - t))) - (throw 'match t))))))) - (funcall match (list condition)))) + (funcall (or (gethash condition cond-cache) + (puthash condition + (byte-compile + `(lambda (,buffer-sym ,arg-sym) + ,(funcall translate condition))) + cond-cache)) + (get-buffer buffer-or-name) arg))) (defun match-buffers (condition &optional buffers arg) "Return a list of buffers that match CONDITION. -- 2.38.0 --=-=-=-- From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 04 Nov 2022 23:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: 58950@debbugs.gnu.org Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.16676028254284 (code B ref 58950); Fri, 04 Nov 2022 23:01:02 +0000 Received: (at 58950) by debbugs.gnu.org; 4 Nov 2022 23:00:25 +0000 Received: from localhost ([127.0.0.1]:55033 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1or5fl-000170-Gc for submit@debbugs.gnu.org; Fri, 04 Nov 2022 19:00:25 -0400 Received: from mout01.posteo.de ([185.67.36.65]:33081) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1or5fg-00016g-Jk for 58950@debbugs.gnu.org; Fri, 04 Nov 2022 19:00:24 -0400 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 13AD124002B for <58950@debbugs.gnu.org>; Sat, 5 Nov 2022 00:00:15 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667602815; bh=F/sXLNWDxrmVaz9NXg3JdkL54yuregoCr0vvNffAlFY=; h=From:To:Subject:Autocrypt:Date:From; b=SmlDB2WzSD1V/Kejn/jOgd73FVVnAD6+NTo+ujesH8KwFchutazJ3o1XDG7a4ftlo 9VgJ9DtuRDpTkCrFgB0tUIbm19HTA7Q0GojdMNfFAiHtx1p6LEKZykvobUb22XQGLI A80rPbTGGeNT7s6fbrKWTQjaYF7rpaJ994zt/P2gLO6+LiRE1cWWM3uKdF4DCnsJi8 5/Np7sEB7JSM8jZn7uUQ3aHkDkNE3V/VliPmgMfk+TkLsTqc9/sCLrv4/JJrDwRHWU n1nj1dr1ApekO4PQkHpxQ6KmczMhZLkzAeYdy1YnWY2gBb9u/OIMAQXoP8YRWUZqVW pJ/X4N2Ikyufw== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N3x0t03Pgz6ttj for <58950@debbugs.gnu.org>; Sat, 5 Nov 2022 00:00:12 +0100 (CET) From: Philip Kaludercic In-Reply-To: <875yfyebi0.fsf@posteo.net> (Philip Kaludercic's message of "Tue, 01 Nov 2022 19:11:03 +0000") References: <875yfyebi0.fsf@posteo.net> Autocrypt: addr=philipk@posteo.net; keydata= mQGNBGLfygUBDADVznbke6w0n9nE42xb+ZggbBy0IYRkkru/K+NA67523YTl2DoR2a5OMW90w7L9 KDtX2Mp34JN/6jVOSVC07VUbHVu6/exoGKixkiTpGhBPy5tUUJoxQKqLrzVQhN3fIyvg1oyHXKZm QGkUeevV0wjj4++xfjmcP235YvDh3TF8HC9t5KxIQIbhWnQm4ZyDkpWWS2CmdNttlj2+eH+51WLL bgx2bcwTmqrs079Q3hgF3yh44bBEmp9MgFjiZldOY2my0/ZSeucRxYmiM0vbJEBQgZV/MvA3gTxe 7ibV3ii7AyoYA8FiFDP98S/R2y5Nfq3ez9B7qeqtpSNseQHOU7h8Y5VV01a71ZszENAmbbwsldb9 j+HRLke7rn6mswDZl1qA/9ZFRzliFOdQtS1878XjraY+h5jfjvxaFVK23prGGVrrKv0LPWavoFUr nsjeHEZhYezBKhC2PwvRtXm01S3rkNbwm9pj0tfLSDW+1pT+6eZWptfQCXF2oEvgfKSTASUAEQEA AbQmUGhpbGlwIEthbHVkZXJjaWMgPHBoaWxpcGtAcG9zdGVvLm5ldD6JAdQEEwEKAD4WIQRxJuHe LwzjXHcL7QHyw8xRPbifZgUCYt/KBQIbAwUJA8JnAAULCQgHAgYVCgkICwIEFgIDAQIeAQIXgAAK CRDyw8xRPbifZkH+DACmCKmhrYgcv2i6dj3vRCVINaLtKUODTna/wAmP20WRKPhqvqvKNUx/wzpT aZrXIxpxOU2xawRWeHhWUktxS+W9L3xTACeR0gf5gomCxD9RuBTIohzWDkQt5rk8QwLqx5rAy5zo feXujnDCXkZtodo1m54cY2kUFF/WIYRrciL/EBzpcizybMJFwx4HxSBlGRkdwnSH9Dzo+4U+8ctB xDfTvQ7cK/0+Qz/TvKjUK8LXLN1/rJTmqpRDv+Odx9LaxutGGoXeLwmhhgpRhvUS8EsqHGF37Zxe AV/ybdVU4NHXVecZAhSgOXX4EHDa7NjhTihx9Id478aQycOKf3CiI6Z8AgcR/iKE4bD4osh2cqQB +JIBtktImxJ1vFsehdQVjdLPWqlr/1weMHM4xH/4VtCLOl5mO3K+fUWxQ/DGLXeQVZ+hilITSKMl YVH/7he26WGd9FRJR25t9uTSgL2YIG8xYppKXueyK/5zjHq05UZRFKiFuPTE4Daoemqx86vYlui5 AY0EYt/KBQEMANvhe1fPQ3BHBcE2GfdX9kVXV0uAP+2Be2DxKWPJI1SqZbrS4wSUsDdd2+2m4YMX E3d+K9Z6IqBcr5gMFSN9QKGEo91FYYgnqvtnd6n9sEAScfNri2GVJzlmXAtEAWeVlv83cu0v0Gsw rSKkxZfMxt+EodtN0aswf5SAy77t28NZUw4fk/0o0AlIMjByVcDkipn7N02gLHjYsvMGFFtM3Zqg Fps8ix3XytSg3Pf8hIVhXFGkBs/iN6dGeIs8wVWBsB7azdqE84uUSRAcS4ymqUE6KxsbNo4x8RAx 9Pt2fcL5bWURAZB+83dk8NVmoQdtY+d4JUV9RAKM/Qg/qtE0fVxcZnj8YmxB1NzLf0UxgHuGYtaq HWrB80CROxMzK7fH8yDRnQKHT2gJYMMQjzMwakSSk8bNJDGBTvAbnxSbYMUC3FR4Pz3pSAbsaSz6 LY0QHDRlroBpyJHatrtKh9Uf9nV0wPIKgZfaH2mhiU17/N6wx0W12cBhrTDRoSnTYIgvQQARAQAB iQG8BBgBCgAmFiEEcSbh3i8M41x3C+0B8sPMUT24n2YFAmLfygUCGwwFCQPCZwAACgkQ8sPMUT24 n2b4ogv/Z5HKvWT2hB238G0ZrUxBptNdQHSG3VwfghN30KH7AEW8ZxsDn3zckn/jXxob4VyhUC8d zZdBQstsNgl+NZ7S2JYRUEsIpoRiHnQFJnfPpt6YZMVNYHJkuh7zRIQGji4OoS8j9QdUHsJnQDia xElXx2vwcBTRZBybcNC+3scGgFBzAcrI4AhYjKZBj5lvKMTrWhK+o4bVdFaYTJDIq37MM3IQLzFF oPIB1C525V916wVYSVl7+RQ1T/mf9oX9kZcYVTC0g4KBEEDI4SGK0i5sKDLfBp4c91AFlUo/J8nC hUMWblnpfCC7epUEbrms0ZQE7RFLgy7YCLZ9Fx2JfV6gx9n9vH7kI605uLnTHgkw3uED/CKfVlbW v0Yrtvi0rUMunLnlySIpXItkSIK+PCqTMdLJ3rBe0ALPgbKN6Lu+yxfe0eaAmFbrNZFI0xp40403 gDwhwoq742fLwbxPSldSeb8A93KRg/8e92CMwKVYtxoADeoksMq10iid4POQl2vw Date: Fri, 04 Nov 2022 23:00:12 +0000 Message-ID: <878rkqjpfn.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Philip Kaludercic writes: > Tags: patch > > > The below patch is based on a tangent discussion in bug#58839, the below > patch was written in collaboration with Jo=C3=A3o T=C3=A1vora. It involv= es an > optimisation to `buffer-match-p' that dramatically speeds the execution > of the function. This is important for the very least as > `buffer-match-p' is used for displaying buffer. > > Running (benchmark-run 1000 (match-buffers "\\*.+\\*")) I previously got > (22.822269875 178 15.524474267999977), and with the patch applied > (0.27100275 2 0.1730835160000197). > > There are a few points that can be discussed: > > 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? > > In GNU Emacs 29.0.50 (build 3, x86_64-pc-linux-gnu, GTK+ Version > 3.24.30, cairo version 1.16.0) of 2022-10-31 built on heron > Repository revision: 462a66e79edcc34ecbeef7cc1604765adfdc038e > Repository branch: feature/package+vc > System Description: Guix System > > Configured using: > 'configure --with-pgtk --with-imagemagick > PKG_CONFIG_PATH=3D/gnu/store/ssg343s6ldqdwh30136pnawhbgd0cb6i-profile/li= b/pkgconfig:/gnu/store/ssg343s6ldqdwh30136pnawhbgd0cb6i-profile/share/pkgco= nfig' Ping? From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Nov 2022 01:05:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Philip Kaludercic , 58950@debbugs.gnu.org Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.166778309029383 (code B ref 58950); Mon, 07 Nov 2022 01:05:01 +0000 Received: (at 58950) by debbugs.gnu.org; 7 Nov 2022 01:04:50 +0000 Received: from localhost ([127.0.0.1]:60944 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orqZG-0007dr-4v for submit@debbugs.gnu.org; Sun, 06 Nov 2022 20:04:50 -0500 Received: from mail-wr1-f52.google.com ([209.85.221.52]:34551) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1orqZA-0007db-Lj for 58950@debbugs.gnu.org; Sun, 06 Nov 2022 20:04:48 -0500 Received: by mail-wr1-f52.google.com with SMTP id k8so14142958wrh.1 for <58950@debbugs.gnu.org>; Sun, 06 Nov 2022 17:04:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=qzu3dA7mFWJmo4aSwSsRj/PbqS+lVjQKUWXRVGrx3Vo=; b=TpFtkLICGd8YMmLdKztdpEFaNU84sxwM7vcv/qblfQ2zVvy//BDedOu2ZrQ7SRz9cA Vh7hP3YY2dAkhPuODb9Lql/MSRnCwnONOy6QmQAnC8+HXzZafc0PIb5oPMc52oxoN/Dn isBLcfO8xLPBR7agmISTjyJlQcNHewCznSDjqZOSem7HybF4cGjT1QXup0Rb4SSLHRpW B8ggVScYzM+dpXvnUhCmXlW7E2YvNJRDqj7wexC+L/bDU1l816H5BTvlH3XWV1bjrwHd lUWfvqgmuNFJ7G9zjjZN4jfZbA4rhKzgoSJ9keYoriSAjiig6lwPGutbNbeXtTFnCIwg F4Yg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=qzu3dA7mFWJmo4aSwSsRj/PbqS+lVjQKUWXRVGrx3Vo=; b=wL0BzF2Xr7sHDtR9+oTp1uy1SddS2hqb5WsHqpR7FgnrlAG3vP5aWjawijH/UJTlaE JVO6tglpmYOkirmKTTR5un44798GHqRD1x+UGVG14lM3reQcgKoMmQJsvm2Xh00cBlwf D/w2PxaOzbeZBn+BjtF4Joj2gVTDtHA3FgfRk0RAX1UU2WB2SgPzvxmVFDhvjWyND3g4 l4ZwIM/u0xGgy+TS6AbmXFau2yhQOvhV9aapfoaJ17WwL1xQmJTZudXszFJGJLdskHLp iF0wgmWrpx/J33ga2RCnwDl3RFvGDYM8h9gbsLrRygKWcyQX4d0EGMVxujMBJ6QdqfQa WsRw== X-Gm-Message-State: ACrzQf2hnT02N+EIxXrQZhNOK57RVVX2uMDI+cZF6G09pyZUdc1pU5Qc WYMVoH0H46TjMJRjY65Ha74= X-Google-Smtp-Source: AMsMyM6WsAkgMm+chpw2U428mLPwOIdqpm/GL38uXyNgyvyfQXE61Oy/3BQV9llRCayMrzdpsJ1p+A== X-Received: by 2002:a5d:4711:0:b0:236:48b6:cb89 with SMTP id y17-20020a5d4711000000b0023648b6cb89mr30364336wrq.246.1667783078710; Sun, 06 Nov 2022 17:04:38 -0800 (PST) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id j7-20020a05600c190700b003b477532e66sm27918395wmq.2.2022.11.06.17.04.37 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Nov 2022 17:04:38 -0800 (PST) Message-ID: Date: Mon, 7 Nov 2022 03:04:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.2 Content-Language: en-US References: <875yfyebi0.fsf@posteo.net> From: Dmitry Gutov In-Reply-To: <875yfyebi0.fsf@posteo.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.3 (-) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) 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. From debbugs-submit-bounces@debbugs.gnu.org Sat Nov 12 15:34:41 2022 Received: (at control) by debbugs.gnu.org; 12 Nov 2022 20:34:41 +0000 Received: from localhost ([127.0.0.1]:49171 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1otxD7-0004nm-5v for submit@debbugs.gnu.org; Sat, 12 Nov 2022 15:34:41 -0500 Received: from mail-ot1-f53.google.com ([209.85.210.53]:42553) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1otxD5-0004nX-Tj for control@debbugs.gnu.org; Sat, 12 Nov 2022 15:34:40 -0500 Received: by mail-ot1-f53.google.com with SMTP id a13-20020a9d6e8d000000b00668d65fc44fso4620506otr.9 for ; Sat, 12 Nov 2022 12:34:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:mime-version:from:from:to:cc:subject :date:message-id:reply-to; bh=zBRPi+jwqMOrZAE2bj9M8vNMYfc3lwbxcDEwojGtc/E=; b=cmkr5rtXYOQ/lKF4H7+sgUC+xPUcf1ZDalLcU5sR85Ko5od7r5rk7PsEROQSf+GvER stE+v4+LMDJjRvyNMH5Ab3KTQIQ2BzhgzfKSDOT+WkivaOjte3N6q6hRoMN6kYiX6l3l 1gJwmdvSnYluKGmHwmwsLl+wxIPpcOufiZ4nUsaxQDPzhKsPEOxnpwfuZeiG12aEk07Q ly55JIyx1bKKm/jp4tmrmk60XoEfTDj+TGLxRhyaXg8JDQM58h9EvpzuGk7qAoXvLgs7 nxbnKXbLu1zdsbhkh6i++sBGiT9YqrRNNPAdDLdg2iIYTf0vIu4yL6vkOV2keXdEDfPO Dx5Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:subject:message-id:date:mime-version:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=zBRPi+jwqMOrZAE2bj9M8vNMYfc3lwbxcDEwojGtc/E=; b=5VPixV+TbFxare5DEEfs81LYEY8U6e3VG8oZTGPTxuod9g3n4YoQ8iNsmQD/HghMqK mYY+3qZwJqmdS3WMJCXR56yRRoW2fjvYGPWCQRTcwM4ZJ07TbTC53WMCWIa6FEg3JfZs h8KUnb4JZT9FEqqg+SVKOR203ApfTonnOmwhWJRSgQUc4EhoVd3fpPPOPb81qg6caRDa UHK36+Vsu11lMdJBunuzYa/AcItBsPvDxFuRSdI1AqZWqIN0U2X7j561pudi2KHs/LOh JgGgl3vM6ZBfuYAg10FQvprA1pv6WPtpZbofVK30NtyxoMz1TPYXL7r31zpfZRo9eGdV QdwA== X-Gm-Message-State: ANoB5plOfWxpE1/JlEgTO8sQlO+/A8av3Dy55vgZ6fc+mQiT7Hd4Jksz AIZfwRihx9T+dzDXYpbR4qpKMuzVYqCAaLzs6N5vbL7Q X-Google-Smtp-Source: AA0mqf4wJlOtTS7UBFxIKxdTlxkqdkoVYQUyvx2kHxThATjcS6PujOfLP9kthd0Irmxr9D2A78rAqzVReaE0Rj+jifw= X-Received: by 2002:a9d:4f10:0:b0:66c:5232:b9d1 with SMTP id d16-20020a9d4f10000000b0066c5232b9d1mr3721957otl.224.1668285274490; Sat, 12 Nov 2022 12:34:34 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sat, 12 Nov 2022 12:34:34 -0800 From: Stefan Kangas X-Hashcash: 1:20:221112:control@debbugs.gnu.org::mmpYfKG/GCKTWIrA:nGD MIME-Version: 1.0 Date: Sat, 12 Nov 2022 12:34:34 -0800 Message-ID: Subject: control message for bug #58950 To: control@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) severity 58950 wishlist quit From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 31 Dec 2022 13:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: 58950@debbugs.gnu.org Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.167249497932273 (code B ref 58950); Sat, 31 Dec 2022 13:57:01 +0000 Received: (at 58950) by debbugs.gnu.org; 31 Dec 2022 13:56:19 +0000 Received: from localhost ([127.0.0.1]:36798 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBcLS-0008OT-Q7 for submit@debbugs.gnu.org; Sat, 31 Dec 2022 08:56:19 -0500 Received: from mout02.posteo.de ([185.67.36.66]:57061) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pBcLQ-0008OE-61 for 58950@debbugs.gnu.org; Sat, 31 Dec 2022 08:56:16 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 5E68224024C for <58950@debbugs.gnu.org>; Sat, 31 Dec 2022 14:56:10 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1672494970; bh=jbDVyM6/x8gjcT86TK3jHbBUeMe5t4rJaXCPVie3y78=; h=From:To:Cc:Subject:Date:From; b=c93KTAS6uxiGBSgmSeduqCn3/JS1SN34Rxc0w8IMnd4yIjTnvl1WlB/MG6DwDAvUb S6ZxodPT8bMnrdfB1JgUyqMjQZYjoABFdCF8vZEQhjIx9PZt45vDkDkuwPQDPWET+J XottXPFfUUSAAu0adayauEpTcmF3OC2y3H95cPUsJCIXG3N3iP/bYbR/DG0sgHIK6Y JUCf8l8e3hJJpPkckGoFuQ1BHTlMCiyBbnS6CEOsHLs69fMaUTEDjU5tqGnk1DgIUo UqbVhW92zaBzC57tOm7CqSYwWXlkgzpr6zc6vdUP7RYqVQ8RHNH8Z0LxMHBzkpjx1C ze76kvNpc6HaQ== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NkkDn4W2Tz9rxF; Sat, 31 Dec 2022 14:56:09 +0100 (CET) From: Philip Kaludercic In-Reply-To: (Dmitry Gutov's message of "Mon, 7 Nov 2022 03:04:35 +0200") References: <875yfyebi0.fsf@posteo.net> Date: Sat, 31 Dec 2022 13:56:15 +0000 Message-ID: <87a6331xts.fsf@posteo.net> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Dmitry Gutov writes: > 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. Ping? If this change is too controversial, I'd like to backport the changes from bug#58951 and apply them since they are fixing an actual bug. From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Jan 2023 00:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Philip Kaludercic , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Stefan Monnier Cc: 58950@debbugs.gnu.org Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.16728768223535 (code B ref 58950); Thu, 05 Jan 2023 00:01:02 +0000 Received: (at 58950) by debbugs.gnu.org; 5 Jan 2023 00:00:22 +0000 Received: from localhost ([127.0.0.1]:49881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDDgE-0000ux-HO for submit@debbugs.gnu.org; Wed, 04 Jan 2023 19:00:22 -0500 Received: from mail-wm1-f50.google.com ([209.85.128.50]:35452) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDDgC-0000ui-Sv for 58950@debbugs.gnu.org; Wed, 04 Jan 2023 19:00:21 -0500 Received: by mail-wm1-f50.google.com with SMTP id m8-20020a05600c3b0800b003d96f801c48so157763wms.0 for <58950@debbugs.gnu.org>; Wed, 04 Jan 2023 16:00:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=BWpOvY5J0xDS5QvTNgov3kXoG8cZ/oDUMLwdJw/jwxA=; b=mhoVKN4/uT0a+i7cG90zReVZ1PEbPj4wR0B3yGEB2MtLgPM9vxZAHnFIV7iCdQjd/N X53TtZZBM/y6DRepqXxD7DinN5HqXP35yTXGJjHQakc0huy2rmtwHQXQEzPoVKvRpEQl kF2TsIejXzQw7Ig7H1MSQiQfHWxtwmJuF4/HhvFzE3UoWHqj8d9fxSDd8FwGGzZzbhk7 KUdeRE8PTHEXqdfo3z23jZQOuLPWjpQZ1dGni0zbZBi89DY/VpzyxvG962wm+/8+NzHb B8LMgViEnTWFdRloTa0nixDB/mKgwZUzovYoqCtRjHTN7d/OmOALmWnnvgbKTX0GUt0v W9Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=BWpOvY5J0xDS5QvTNgov3kXoG8cZ/oDUMLwdJw/jwxA=; b=z9XFXrsXjYkJ0uAJbzrzwhs9cglhmdPWjuedwa/VjLamqNV1jkiikD1NdfbIUhfg+D eyIbvsHaAEgTnENzp2Lg5Icpg3McT0Z9Ur6VvlUIEpN5rdDFiyJioz2dgOmr+a87htVR /xDWTRzQiv+TyAki5/j1ccMuF62CCJTELIvZKefPZGDV6JlBNxAyZwO2mMOppWsJTxW0 rp7k9WBpgaByN9ZlI/hBaf8cB4MuBvKSpUeuCxdXjjq6Wl2GUVKW/XKSrW2D9ZRAouza XmEOr5EPDeQ8A3TipALVlKLQYuSdHa59kHqKVJ0xHYiz5dQAlH4at3aH0ao3/Xr+59QF arkg== X-Gm-Message-State: AFqh2krnwYYTolKYBg1vb8jIUHYq5Nu3zQAMpAL0beTThme9Ujoz0lw7 +Y4dnN8HjlLVw2wNDfi2aO0= X-Google-Smtp-Source: AMrXdXsI+9Qb83M/+q1ubceR6dU5LdHHU4jCKphrwAfp3pZeDpH6cZkdvPY18V4xawaObYEz1RhjSg== X-Received: by 2002:a05:600c:3509:b0:3cf:ae53:9193 with SMTP id h9-20020a05600c350900b003cfae539193mr35166400wmq.39.1672876815062; Wed, 04 Jan 2023 16:00:15 -0800 (PST) Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id r7-20020a05600c458700b003c6b7f5567csm4873334wmo.0.2023.01.04.16.00.13 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jan 2023 16:00:14 -0800 (PST) Message-ID: <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> Date: Thu, 5 Jan 2023 02:00:12 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> From: Dmitry Gutov In-Reply-To: <87a6331xts.fsf@posteo.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) On 31/12/2022 15:56, Philip Kaludercic wrote: > Dmitry Gutov writes: > >> 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. > Ping? If this change is too controversial, I'd like to backport the > changes from bug#58951 and apply them since they are fixing an actual bug. It does look too ambitious for the release branch. On the merits of the change itself, maybe Mattias or Stefan have some thoughts? From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Jan 2023 00:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Philip Kaludercic Cc: 58950@debbugs.gnu.org Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.16728769353749 (code B ref 58950); Thu, 05 Jan 2023 00:03:01 +0000 Received: (at 58950) by debbugs.gnu.org; 5 Jan 2023 00:02:15 +0000 Received: from localhost ([127.0.0.1]:49885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDDi3-0000yP-1M for submit@debbugs.gnu.org; Wed, 04 Jan 2023 19:02:15 -0500 Received: from mail-wm1-f48.google.com ([209.85.128.48]:36745) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDDi1-0000yA-7k for 58950@debbugs.gnu.org; Wed, 04 Jan 2023 19:02:13 -0500 Received: by mail-wm1-f48.google.com with SMTP id c65-20020a1c3544000000b003cfffd00fc0so143112wma.1 for <58950@debbugs.gnu.org>; Wed, 04 Jan 2023 16:02:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=d1lfdpFUKvRNt3SH508hjiLvGgmafC+lkO7KgZanYWU=; b=FbdfG1BiFyfjZqqDLir2bO+kmUTr893m1ugfC08diWzQTltiw/iAHDh7UXQsJf/6xt eYSl+l+tsbrVqUaojdZMgSoLV6LIuqP+VGNPuHhGXa8VHaDWtkBnA26RLaf2tbhOmtgg IR0lzY3bMxr5RwaFPFbPH3yW6ZbX2JHtijn1atZhY36mZW9ejAfOJ2ONBgEWlRO9irqH i0XbdiVaWajliD1uJ7D2mxrY4EJIoaYgIIOc/xuR7CZHlNw/z27/ZIoCeaYRObnjCsP7 +MKHIf9E0BDaBNy/QZoUFhc0SktKtSsWvVAaEbdo3nDJKoYzgJnIncl8fRvOCHhxZPHB tQEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=d1lfdpFUKvRNt3SH508hjiLvGgmafC+lkO7KgZanYWU=; b=WQnB3GsKARfhCnV+Pe8KmwrAGjF9UWDH3Ks4d9qFR1mSV9zrVCIXPZbOhc+2skSgN4 cOmJfKJKKlCgtgDrw/DvrthHNnuvUl4NYCcL0byPXYznQh/tnVdcitL8vSubx82ipZkS 5Gt6IdvBa1Hzr5qzHe7Otzv7LT5lZYo7xs9XXcWGPLd+S2HeAuuH+cGCbBRoyKVXfC3K eTwdjR2slc1gZQmWoLE+g/nwfB1ne7n0DKS3g+YiwEBP3L7GEjl5hoZIwOty6OvRB150 I/VV1g/7hCGpUjzKH0c7lNR5hIXb0nygJx/7xrv/plKqOHDqjnw17IKka1pi8SA7etnw Gc1Q== X-Gm-Message-State: AFqh2krUZY2eXTPbW3QmkryQFLJNkcYo72XPcOALIeOHSCP8+Nd95WJt n0Awt6kRxGgukqJZBUH1NKU= X-Google-Smtp-Source: AMrXdXsTHtAtWEjqA2G4S2a5IVwDj+YFVHyhRo7fLjQnJ+b7c2joG0Mk3IYLStTmW2hcjqerC/UhKA== X-Received: by 2002:a05:600c:4e53:b0:3c6:e60f:3f4a with SMTP id e19-20020a05600c4e5300b003c6e60f3f4amr33803073wmq.1.1672876927712; Wed, 04 Jan 2023 16:02:07 -0800 (PST) Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id fl9-20020a05600c0b8900b003b3307fb98fsm394392wmb.24.2023.01.04.16.02.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 04 Jan 2023 16:02:07 -0800 (PST) Message-ID: <9614ebe2-4cf1-30d9-55d2-71a0488f0c2e@yandex.ru> Date: Thu, 5 Jan 2023 02:02:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> From: Dmitry Gutov In-Reply-To: <87a6331xts.fsf@posteo.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) On 31/12/2022 15:56, Philip Kaludercic wrote: > I'd like to backport the > changes from bug#58951 and apply them since they are fixing an actual bug. Speaking of backporting, though, could you address Eli's last message in bug#58951? Also, he seems to have reverted the change in the code, but not in the docstring. Could you also clarify this for me: which of the semantics for 'not' is going to make 'buffer-match-p' a compatible replacement for project--buffer-check? I assume we do want to drop the custom interpreter inside project.el someday. From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Jan 2023 04:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Philip Kaludercic , 58950@debbugs.gnu.org Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.16728930988275 (code B ref 58950); Thu, 05 Jan 2023 04:32:01 +0000 Received: (at 58950) by debbugs.gnu.org; 5 Jan 2023 04:31:38 +0000 Received: from localhost ([127.0.0.1]:49992 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDHuj-00029P-LQ for submit@debbugs.gnu.org; Wed, 04 Jan 2023 23:31:38 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:45916) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDHuh-000297-EV for 58950@debbugs.gnu.org; Wed, 04 Jan 2023 23:31:36 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 743278056A; Wed, 4 Jan 2023 23:31:29 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 6F996802B7; Wed, 4 Jan 2023 23:31:27 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1672893087; bh=Z0humiN0YST2JJc9BmrUD+VqCBapHXIoBHEr2q1pP2s=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=GF96z1QTnCQyx5YNYnnXkKVDDdKqWjW7J7YP48WsDQqpr26pPKhtA6Z5g3o7wVZJz EikCGsWHI/Fuzih86mc96KwwguwaT5+gf9y2GbBjdtYv15YDDHozfhsFsaTwBioGcP L3XhqnsrKV4Lj+EEXbtpkqJa0MV7UA+Lf2bfdKLDooRdNnV0F1zxmRarDMKTfcjiHb X0/orc5R2ybnjwQSHsdeKEyUTmWTO6fOhZsOi9jFpj2F1QdkacX9UMQCdxeeBwseDe wzTKCzyqZUiz1ChWInWCRrPXpyIJw8SUgr2Qmto6IU13CCE2RiRU3ZU9nNQSwNuAcm wxJnHczkhcoDw== Received: from pastel (unknown [45.72.200.228]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 29B5D120978; Wed, 4 Jan 2023 23:31:27 -0500 (EST) From: Stefan Monnier In-Reply-To: <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> (Dmitry Gutov's message of "Thu, 5 Jan 2023 02:00:12 +0200") Message-ID: References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> Date: Wed, 04 Jan 2023 23:31:26 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.318 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >>>> 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? You could make the hash table key-weak (since the test is `eq` it will have no detrimental effect and will avoid most risks of leaks). >>> 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). >>> 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. To be clear: I don't much like the kind of mini-language we invented for `buffer-match-p`. I'd prefer we just used plain old ELisp for that. It's a bit more verbose for that particular application, but: - we have a much more efficient interpreter at hand. - it's useful for many more things, so it's much wore valuable to learn it. - it's a lot more powerful/general. Stefan From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Jan 2023 06:33:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: philipk@posteo.net, 58950@debbugs.gnu.org Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.167290034121897 (code B ref 58950); Thu, 05 Jan 2023 06:33:01 +0000 Received: (at 58950) by debbugs.gnu.org; 5 Jan 2023 06:32:21 +0000 Received: from localhost ([127.0.0.1]:50058 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDJnZ-0005h7-9A for submit@debbugs.gnu.org; Thu, 05 Jan 2023 01:32:21 -0500 Received: from eggs.gnu.org ([209.51.188.92]:35044) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDJnX-0005gv-BF for 58950@debbugs.gnu.org; Thu, 05 Jan 2023 01:32:19 -0500 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pDJnP-0002ll-Tt; Thu, 05 Jan 2023 01:32:13 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=GAC3bZi0eusjz6UvKsp8tc8gLG8gQR9rJDbvdXXZKj8=; b=cUMbm5uQFW5o ndJLePZtr0Nk7pOk5OM/RzVjfS0uHBfW4xL0xs0UaUythFf/a0MeisKG1BjqT2CMyszCrJok4NbAl YF6zRXMpql7I3DzjoE4taY6ibzrHKXGWmqamtX3RaLCNo2UoitAHio5ViY/8MPRxCFfYHC1Jn1Z+R WScH+SBtqYIsZnUMnhhZvr6w5tUX4pDcJt5JQki6RzEikNfynhyfP+Q3wO5b6UPG71FZGv/ns//Vt fac6hrZTPCscQsRVa2EWe4RdeVSaYv0Wo1xcloHO0o+3YXFYyhxM9byfD9a8Qxt5c84q9RS1Lf1VF QhlhVGwD0+dWqe8799Qe0Q==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pDJnG-0001nv-FE; Thu, 05 Jan 2023 01:32:11 -0500 Date: Thu, 05 Jan 2023 08:32:15 +0200 Message-Id: <83k021xzio.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <9614ebe2-4cf1-30d9-55d2-71a0488f0c2e@yandex.ru> (message from Dmitry Gutov on Thu, 5 Jan 2023 02:02:06 +0200) References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <9614ebe2-4cf1-30d9-55d2-71a0488f0c2e@yandex.ru> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 58950@debbugs.gnu.org > Date: Thu, 5 Jan 2023 02:02:06 +0200 > From: Dmitry Gutov > > On 31/12/2022 15:56, Philip Kaludercic wrote: > > I'd like to backport the > > changes from bug#58951 and apply them since they are fixing an actual bug. > > Speaking of backporting, though, could you address Eli's last message in > bug#58951? Also, he seems to have reverted the change in the code, but > not in the docstring. I hoped the problem would be fixed very soon after the revert. If this is not going to happen, please adjust the doc string, or tell me how to do that. From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Jan 2023 10:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Stefan Monnier Cc: Philip Kaludercic , 58950@debbugs.gnu.org, Dmitry Gutov Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.167291467722891 (code B ref 58950); Thu, 05 Jan 2023 10:32:02 +0000 Received: (at 58950) by debbugs.gnu.org; 5 Jan 2023 10:31:17 +0000 Received: from localhost ([127.0.0.1]:50348 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDNWm-0005x9-MN for submit@debbugs.gnu.org; Thu, 05 Jan 2023 05:31:17 -0500 Received: from mail70c50.megamailservers.eu ([91.136.10.80]:33190) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDNWk-0005x0-Eq for 58950@debbugs.gnu.org; Thu, 05 Jan 2023 05:31:15 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1672914672; bh=10gajO31+7HlqlSmLk5jjXk2FTSvn/kDXLPjbq+BH5Y=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=UHrhLXrUh5q/IB46IcODywkqRyMtaNgY1hBTrrWL5ALzl6Qdy0AHJbxzIx6Q+Pi1Q unEc4jqFydCcA/BR8bYzrUHru7Bm3CS/olXfeDDxYyT68yYJYkRZKSliew6rEpJGL2 eNQ5YUEIyA2LxIvDtE0FghnkdvlVJ7QVgxlJmddA= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c188-150-171-209.bredband.tele2.se [188.150.171.209]) (authenticated bits=0) by mail70c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 305AV95q080441; Thu, 5 Jan 2023 10:31:11 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: Date: Thu, 5 Jan 2023 11:31:08 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <255D9E93-422C-4A43-9876-751FDB8E61DB@acm.org> References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A782F25.63B6A6F0.006C, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-Origin-Country: SE X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 5 jan. 2023 kl. 05.31 skrev Stefan Monnier : > I don't much like the kind of mini-language we invented for > `buffer-match-p`. I'd prefer we just used plain old ELisp for that. Yes, I sort of wondered whether we were going full Greenspun here. We = haven't added many embedded languages into our embedded language lately. The usual DSL worthiness criteria: - more expressive than plain code for the domain - potential for significantly better performance - better error-checking, statically or dynamically - structured editing etc, don't really seem to be met here but I'm not deeply familiar with = the problem and perhaps the author could make a better case for it. From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Jan 2023 12:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Eli Zaretskii Cc: philipk@posteo.net, 58950@debbugs.gnu.org Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.167292296823135 (code B ref 58950); Thu, 05 Jan 2023 12:50:02 +0000 Received: (at 58950) by debbugs.gnu.org; 5 Jan 2023 12:49:28 +0000 Received: from localhost ([127.0.0.1]:50487 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDPgV-000614-Vz for submit@debbugs.gnu.org; Thu, 05 Jan 2023 07:49:28 -0500 Received: from mail-ej1-f51.google.com ([209.85.218.51]:45781) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDPgT-00060p-Tu for 58950@debbugs.gnu.org; Thu, 05 Jan 2023 07:49:26 -0500 Received: by mail-ej1-f51.google.com with SMTP id fc4so89706948ejc.12 for <58950@debbugs.gnu.org>; Thu, 05 Jan 2023 04:49:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=CQUkgQpKvgKp1yG9uqY+PpLJl+7I8M7fhZ+hW5XlijQ=; b=KWFjy+1BtZrN24jrmep249dOOJ7h63a4yPCsIi3cp0xc+fwzxNBzK/+a/UZmqdiNd8 br42H2ntic2rU06jHYfALUqbigAXCfp1TvcQxQE0lPGATU0ZZMu6wfV0w9QTiDrC9NKa U4GB8pRKmkOScSS1D4EQI1bMU+ywSWhSx8Y0pJ6mArAuo5iTL6OpJ/4T6MCcCOnTCsGd RDfoU1FWxl/NbvYlIDKKaVyTEJ6PKBUHQvFi98GkloBaKXWyrE2Z7HwFXx47ciJHLPtG PTHQtWjp2m4PNAXET+GhLzkR4hl42H6cDBOIzqi0O7Q3/BfNAa+UMg8fADht6AywKkSM 5Shw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=CQUkgQpKvgKp1yG9uqY+PpLJl+7I8M7fhZ+hW5XlijQ=; b=GZo+vksSX1yXqt4pE6VlKxr7PG2o4q9BxfYcJDL7Kso9EhuDhDIPe67/H3pKaLn0Wz 3vgsM2QsKdqIFXqz4N2QZ0YdIEfVAyWYl9F4DK2QmxJUyctvYw5ujh3qmXCSywp/Tt98 nraoV1sTa9LYAmOCiWceKIqw4tmOcbWjyMpW8oTpo8i2ZAoQLaMRxVrXCX231cCu+n3p ijeXpfDZIf+MamWK3zrMyo62IR46S/XvRJtEVxU6EjMdOhUBEfqIatS7Osh2mrr1runj qXIMXvoz93BEeGjjmzcg020ysD2MNVv9gWhTniZEn782kxa+1cN9gyuFw2yUrw/TqueJ 6Bmg== X-Gm-Message-State: AFqh2krJgNkwvmmA3MpOrjnjYzY/Tt21QfXi/nU2gFmaQk6aLEPaH8+n tohsXOeKyY4qRLbA8Ab7Q20= X-Google-Smtp-Source: AMrXdXurW7QoQmiCTkmsrTwN7yAuLE9KFVAfNn0gEVE5Nizc0uxnDMKbW7+HmGyzk9jW1jSfHFpbxA== X-Received: by 2002:a17:906:4cd2:b0:7c0:e5c6:2a74 with SMTP id q18-20020a1709064cd200b007c0e5c62a74mr41011712ejt.34.1672922959784; Thu, 05 Jan 2023 04:49:19 -0800 (PST) Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id t15-20020a170906608f00b0078d9cd0d2d6sm16806097ejj.11.2023.01.05.04.49.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Jan 2023 04:49:19 -0800 (PST) Message-ID: <12687b52-fac4-adf9-a135-e203d1b8eb77@yandex.ru> Date: Thu, 5 Jan 2023 14:49:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <9614ebe2-4cf1-30d9-55d2-71a0488f0c2e@yandex.ru> <83k021xzio.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83k021xzio.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) On 05/01/2023 08:32, Eli Zaretskii wrote: >> Cc:58950@debbugs.gnu.org >> Date: Thu, 5 Jan 2023 02:02:06 +0200 >> From: Dmitry Gutov >> >> On 31/12/2022 15:56, Philip Kaludercic wrote: >>> I'd like to backport the >>> changes from bug#58951 and apply them since they are fixing an actual bug. >> Speaking of backporting, though, could you address Eli's last message in >> bug#58951? Also, he seems to have reverted the change in the code, but >> not in the docstring. > I hoped the problem would be fixed very soon after the revert. If > this is not going to happen, please adjust the doc string, or tell me > how to do that. Looking more into it, it actually seems like the current code and doscstring work okay together. The original description of bug#58951 seems a little confused, given that show-paren-predicate was already written in the style (not CONDITION) and buffer-match-p was apparently working fine with it already. The revert that you did brought the previous (working) code back. The dosctring was problematic because it didn't quite match the behavior, and Philip's change fixed that. The dosctring can say (as it does now) that * `not': the cadr is interpreted as a negation of a condition. or it could more accurately say * `or': the cdr is a list of recursive conditions, of which at least one has to be met as project-kill-buffer-conditions does. These two descriptions are compatible, however, as long as one only puts 1 item in said list. So we can sweep the difference under the rug as "implementation details". And maybe there's nothing more to do in there. Philip's patch in this bug, however, (the "Optimise performance" one) changes the semantics of 'not' in a way that would require us to change show-paren-predicate to '(not . (derived-mode . special-mode)). I'm not sure if it's intended or not. Let's see what he says on that. From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Jan 2023 12:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Stefan Monnier Cc: Philip Kaludercic , 58950@debbugs.gnu.org Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.167292331723675 (code B ref 58950); Thu, 05 Jan 2023 12:56:01 +0000 Received: (at 58950) by debbugs.gnu.org; 5 Jan 2023 12:55:17 +0000 Received: from localhost ([127.0.0.1]:50491 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDPm8-00069n-TO for submit@debbugs.gnu.org; Thu, 05 Jan 2023 07:55:17 -0500 Received: from mail-wm1-f51.google.com ([209.85.128.51]:54786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDPm6-00069W-Pi for 58950@debbugs.gnu.org; Thu, 05 Jan 2023 07:55:15 -0500 Received: by mail-wm1-f51.google.com with SMTP id o15so27927975wmr.4 for <58950@debbugs.gnu.org>; Thu, 05 Jan 2023 04:55:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=vBymoo6R9oTo0QffjxtlEaju7+LXEeYU7/QlxTz+p30=; b=oQZhi/Z9d9LdL5Z0gILNNu6SXDLJLxpdXa1SjxzepTat9hW2TYB7aP95eo/71v1XT7 z1eSawUX7kj6EINGeOax38Ou3ehleyDZJ1P4uF8Q3Qo23bcfWvC4yNEh0uGVLwLjYy7d fsLFrMFlFHoeTOTi2wbNHkH06fqwHCYZ+uP0vJXpKigxUf18Bxl2RqjH6Nna9wCAwydm I4qX4ezPXpeZjvZM8QW3bT74sEWzh/lI3eEjZ9tZzIEWUOhXPmrdKX+7xohMf7cCR/sd f2MHHsDx1b5CluLOy0NL/q6ODwbslwqWgULV0X8+hKrb/MgII+V+IXBST7jfxNxFO4Xb wPLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=vBymoo6R9oTo0QffjxtlEaju7+LXEeYU7/QlxTz+p30=; b=yFT1qu6RpSDlJHi5nLxLnCKu7DtgUvqTWnCti4R7F4xBroMIHYvEfd8W/fHYoHZpN3 /8FEz26LWIBrufj2hAHMooOwvBYpyqP2Hk6XmzUdm7tIeIwKdrAENle8OxUbOg3Ktdyo DaPjjcYYJYlr4CqFwCcdCnR1O/O1sTMgezKgsNbRDEkTZD7X4BNh0coRsFDwLZrDNPul rnIRDf3Nza9kiozMDLaiVAcEd0tt04dCGx6FX7rTceCTQITfgtaXOLYRw4nly8gHePTN REFxNqGaawq17URktzNAZMvsrU2lNVDnhIufWuzlf5eWwiJqdJrySdmMXH+AP5O5fAsW /ejg== X-Gm-Message-State: AFqh2kqHBRHtvQzSvpCrdolVVgCgGGaqjnOKdbwcE/Sexf0pbZtuiQbl eEpes94CZn17Msv2L5/UOBo= X-Google-Smtp-Source: AMrXdXumezOVgMhT726DX9k5qg6JvoRYc5wZ4elmjJbz/wwNnxRZOuOVcGFqb+ALQzrEPu8xat/5KQ== X-Received: by 2002:a7b:c3c9:0:b0:3d2:e28:647f with SMTP id t9-20020a7bc3c9000000b003d20e28647fmr43848359wmj.15.1672923308856; Thu, 05 Jan 2023 04:55:08 -0800 (PST) Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u18-20020a05600c4d1200b003c21ba7d7d6sm2153905wmp.44.2023.01.05.04.55.07 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Jan 2023 04:55:08 -0800 (PST) Message-ID: Date: Thu, 5 Jan 2023 14:55:06 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> <255D9E93-422C-4A43-9876-751FDB8E61DB@acm.org> From: Dmitry Gutov In-Reply-To: <255D9E93-422C-4A43-9876-751FDB8E61DB@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) On 05/01/2023 12:31, Mattias Engdegård wrote: > 5 jan. 2023 kl. 05.31 skrev Stefan Monnier: > >> I don't much like the kind of mini-language we invented for >> `buffer-match-p`. I'd prefer we just used plain old ELisp for that. > Yes, I sort of wondered whether we were going full Greenspun here. We haven't added many embedded languages into our embedded language lately. > > The usual DSL worthiness criteria: > > - more expressive than plain code for the domain > - potential for significantly better performance > - better error-checking, statically or dynamically > - structured editing > > etc, don't really seem to be met here but I'm not deeply familiar with the problem and perhaps the author could make a better case for it. Note that we already had ah-hoc and informally-specified pieces of such DSL before, in font-lock-global-modes and display-buffer-alist. The new use in show-paren-predicate seems fitting too. I'm not sure how we'd reach the same goals with plain old Elisp (structured editing in particular -- in Customize). From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 05 Jan 2023 13:02:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Stefan Monnier Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Philip Kaludercic , 58950@debbugs.gnu.org Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.167292368824315 (code B ref 58950); Thu, 05 Jan 2023 13:02:02 +0000 Received: (at 58950) by debbugs.gnu.org; 5 Jan 2023 13:01:28 +0000 Received: from localhost ([127.0.0.1]:50495 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDPs7-0006K7-MR for submit@debbugs.gnu.org; Thu, 05 Jan 2023 08:01:27 -0500 Received: from mail-wm1-f51.google.com ([209.85.128.51]:36798) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDPs5-0006Jr-Vv for 58950@debbugs.gnu.org; Thu, 05 Jan 2023 08:01:26 -0500 Received: by mail-wm1-f51.google.com with SMTP id c65-20020a1c3544000000b003cfffd00fc0so1253979wma.1 for <58950@debbugs.gnu.org>; Thu, 05 Jan 2023 05:01:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=Y+emXmhXhU/qq7sejEwXWMe0t13ZiVn5QEzyz9iaP/c=; b=ktXpw9cwwyHMZepbzmOwBCOZoxHvRNITA1rcO4Rd0n52Td4g7Ww5nXCj8j8IHC1Kbv b+TjwMHk4i0VR1ZIfBFYxzbS6Fe0naLzkx7Fm/OXHYUGxKivmUqTsV0Bxpp7/yRFWo78 WVmPZeq6AMq/EobvI44FkeK9g79z495Vkv9eh4RVap82nOcbt0YMaANBDMOvSnpwF4Sd zGLrChMal/D9wYFBYeC8aFZHXeKAH6+5EGf/0rEz8Y8ut9fGsc7mhiZDooED+aJZF1N2 roKajLhBZSOgZJKzy7C9K464Q8eou/cUs97opyk0dgmxPEYIELKU4jqibQoflwwAsdqC aS6w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Y+emXmhXhU/qq7sejEwXWMe0t13ZiVn5QEzyz9iaP/c=; b=xOaajKMzZf9ILAjOavasgdCkcDGo1SQF4OFMF1HGiLyi9RdhYeO25bkPu3DCwDCr6F z+M2aDQbbM01QnppeVM/hgj2462RrbjqxXwV3uSXKoM1Add0AQ7nAvelb2MS8BbSDp5u FjunSuHTzGTw5OlSZ0SEWx2dZ6gxJzX3N3UAt6X2VBbr4sdjyNq+E5tJZrDcNaDRcmz1 qwCAq9kOCX7UiQyf1jAoFUNOk+U3SsTqa9xc88vu4cWBIeYxk6cKApnEKBhBhhNJ9635 kxRzqo6mI1+/O6G+YSnx8rJfw9l05OjGBzKMi3+RsuDdSrVQT3FKfGZWrtkBGCHPbdXW ssGQ== X-Gm-Message-State: AFqh2kqAu4ldmZ39rKaz9X9AvgikFTOg7Y2Saom/y5qeOhKRlAkFL9DB 21GlB0qReakigPPNYZuy/ms= X-Google-Smtp-Source: AMrXdXuykLKN9TbMMi6hoC9tnSD8pfXpb5OI0o9se+N+3yXfhuMfM0qLmLMhfGRMKc2DlLX/oDPXeQ== X-Received: by 2002:a05:600c:44d4:b0:3cf:7925:7a3 with SMTP id f20-20020a05600c44d400b003cf792507a3mr35945470wmo.24.1672923680224; Thu, 05 Jan 2023 05:01:20 -0800 (PST) Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id r42-20020a05600c322a00b003a6125562e1sm2046740wmp.46.2023.01.05.05.01.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 05 Jan 2023 05:01:19 -0800 (PST) Message-ID: <77d1e30d-a4a8-76fc-925d-9caad2906002@yandex.ru> Date: Thu, 5 Jan 2023 15:01:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) 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. From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Jan 2023 11:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: Philip Kaludercic , 58950@debbugs.gnu.org, Stefan Monnier Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.167300388712219 (code B ref 58950); Fri, 06 Jan 2023 11:19:01 +0000 Received: (at 58950) by debbugs.gnu.org; 6 Jan 2023 11:18:07 +0000 Received: from localhost ([127.0.0.1]:53877 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDkje-0003Az-Ow for submit@debbugs.gnu.org; Fri, 06 Jan 2023 06:18:07 -0500 Received: from mail1446c50.megamailservers.eu ([91.136.14.46]:47844 helo=mail265c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDkjb-0003AS-Ve for 58950@debbugs.gnu.org; Fri, 06 Jan 2023 06:18:05 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1673003876; bh=Zi54u2uEUUhNKrCkCKOybZUvpGvbp5saABNaM6orj64=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=AazZGMEeh+gqtcNnauPQDH2OEDX3CMH5VQYp+1113Ex9e8abaXEYZJ7n3Y27KDeg2 6j1xYkPnNTHH5LeDG820MlFimm5hSmvCoXcYBGb6fatejIDXEXiZhBP3Kik7Vh1jfT 8PZrh17Ex4pZboZmTKhZtTD5hJqriqg+877VeuyA= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c188-150-171-209.bredband.tele2.se [188.150.171.209]) (authenticated bits=0) by mail265c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 306BHrlo037634; Fri, 6 Jan 2023 11:17:54 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: Date: Fri, 6 Jan 2023 12:17:52 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <73923B98-E4B8-44F8-9445-2FD05564ADA0@acm.org> References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> <255D9E93-422C-4A43-9876-751FDB8E61DB@acm.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A782F19.63B80364.00A9, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-Origin-Country: SE X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 5 jan. 2023 kl. 13.55 skrev Dmitry Gutov : > I'm not sure how we'd reach the same goals with plain old Elisp = (structured editing in particular -- in Customize). No enemy of little DSLs in principle but is that structural editing the = main rationale now? (I wish we had (byte-)compiled elisp functions carrying their own = source, either as s-exp, string of formatted source text, or source file = reference -- that would allow for sensible editing in Customise without = performance penalty. But Santa gave me a wool jumper instead, that's = nice too.) Regarding buffer-match-p, the fact that `not` actually means `nor` is a = bit odd (we don't do that elsewhere), as well as arbitrary (why not = `nand` etc) and undocumented. And like all the rest of the machinery, = untested. From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 06 Jan 2023 21:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Philip Kaludercic , 58950@debbugs.gnu.org, Stefan Monnier Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.167304131517353 (code B ref 58950); Fri, 06 Jan 2023 21:42:01 +0000 Received: (at 58950) by debbugs.gnu.org; 6 Jan 2023 21:41:55 +0000 Received: from localhost ([127.0.0.1]:55959 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDuTL-0004Vo-A3 for submit@debbugs.gnu.org; Fri, 06 Jan 2023 16:41:55 -0500 Received: from mail-wr1-f53.google.com ([209.85.221.53]:41564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pDuTI-0004VZ-LQ for 58950@debbugs.gnu.org; Fri, 06 Jan 2023 16:41:53 -0500 Received: by mail-wr1-f53.google.com with SMTP id w1so2491587wrt.8 for <58950@debbugs.gnu.org>; Fri, 06 Jan 2023 13:41:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=MSNQXRfKAiGqM2/Ml1UET7VeiMMySCFwjFKgvw5wNKc=; b=GJKXJBJ9g0o2iwNY3Ph4UVdSZd6assn4gT1L84GwkJarnP+PFYUdz9c2Xvp0vHfgsW snHsFjMZQ6WwbFnikcl0Z6QnzOjxsS4lELX8LovePhyasxQOdIbtloxeGwJlMcYm3f4U kE/N11jQZWOB7299H5yqKxPSkdavamutslnzEXNjWQhnebfuYeGH0osRpx35YYXBhSYg /k7EloZxehgSkbrXhClxnt7YcjNLCruqrJIFs0OIHWFhiSf31Jmqw75kn6ZmEXGLMREX n+t+w5OPhOLIewP5rl46VpGmFEb2HdhOK0brxIxhhgev9wm4XNcMDRTP2ZqALEW4sf8O piDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=MSNQXRfKAiGqM2/Ml1UET7VeiMMySCFwjFKgvw5wNKc=; b=KHKTuAGabAXQ7U+mzNg5wsf67AobVaXXzVM+Gy6NYsAuRMHwf8zd5wK1VkNgyZWbR/ ALA2cO6ETELkRcMqjyyo73kIIT6YKev0C4P6+zZX4ez1hQ8YdgE89l/EZ40I+3SZZh9Q 145SszWlRtE4BpQM1ejRF4o2CIetaqPrQOCY24+4NJS4P3PQyEMj6Xnkgr9jd36OzQ+Z 9Uz0jDPvoalJJyikSerEbL/OXf23M4nGP3lws2eULRZsBMHhrV9DFZ5iWnPlBwzRG7oU 08JoxP7tnKNcAOY7ncTbgCp3+WxzKSFFYefFTqWJ75I622mUmYplC/sl0DcBnKDDI6tr U6UQ== X-Gm-Message-State: AFqh2kqqvq8YZbIDGiF9l5E6BG1MgthzK7kaeCksNnv12NcEQG0nWGio WfFMmknCfcLQjbGLar35aIw= X-Google-Smtp-Source: AMrXdXttrku5LINJVGCyU9Ok5ZARKkMUfhlxThBdVTc3sPEaQulC4G6CCEvlqmDOIWFk8JkvFDwAyw== X-Received: by 2002:a5d:6d0f:0:b0:28b:456c:1b6d with SMTP id e15-20020a5d6d0f000000b0028b456c1b6dmr31518593wrq.55.1673041306162; Fri, 06 Jan 2023 13:41:46 -0800 (PST) Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id d9-20020adfef89000000b002b74be46309sm2166856wro.114.2023.01.06.13.41.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 06 Jan 2023 13:41:45 -0800 (PST) Message-ID: Date: Fri, 6 Jan 2023 23:41:43 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> <255D9E93-422C-4A43-9876-751FDB8E61DB@acm.org> <73923B98-E4B8-44F8-9445-2FD05564ADA0@acm.org> From: Dmitry Gutov In-Reply-To: <73923B98-E4B8-44F8-9445-2FD05564ADA0@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) On 06/01/2023 13:17, Mattias Engdegård wrote: > 5 jan. 2023 kl. 13.55 skrev Dmitry Gutov : > >> I'm not sure how we'd reach the same goals with plain old Elisp (structured editing in particular -- in Customize). > > No enemy of little DSLs in principle but is that structural editing the main rationale now? I think so? And the fact that it's more limited than Elisp means the values have to be uniform-ish. As a result they're easier to quickly grasp. > (I wish we had (byte-)compiled elisp functions carrying their own source, either as s-exp, string of formatted source text, or source file reference -- that would allow for sensible editing in Customise without performance penalty. But Santa gave me a wool jumper instead, that's nice too.) We kind of have that already, if we just made the type for be 'sexp', or a Lisp form. With all the freedom associated with it, just lower performance compared to a compiled function. Would that look like a good choice for e.g. font-lock-global-modes? I don't think the performance hit would be a problem for that use. > Regarding buffer-match-p, the fact that `not` actually means `nor` is a bit odd (we don't do that elsewhere), as well as arbitrary (why not `nand` etc) and undocumented. Yeah, it's a wrinkle. I'm on the fence regarding changing it, though, for compatibility and ergonomical reasons (it's easier for the user to avoid typing a dot). But I'm not married to it either. From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 07 Jan 2023 12:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: Philip Kaludercic , 58950@debbugs.gnu.org, Stefan Monnier Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.16730962444319 (code B ref 58950); Sat, 07 Jan 2023 12:58:02 +0000 Received: (at 58950) by debbugs.gnu.org; 7 Jan 2023 12:57:24 +0000 Received: from localhost ([127.0.0.1]:56681 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pE8lH-00017a-Mb for submit@debbugs.gnu.org; Sat, 07 Jan 2023 07:57:23 -0500 Received: from mail171c50.megamailservers.eu ([91.136.10.181]:53528 helo=mail92c50.megamailservers.eu) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pE8lE-00017O-Ex for 58950@debbugs.gnu.org; Sat, 07 Jan 2023 07:57:21 -0500 X-Authenticated-User: mattiase@bredband.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=megamailservers.eu; s=maildub; t=1673096238; bh=wGBRP73RnPwR2xN2hQWHIt84WTH4VfvLTrfiE9F6xCk=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From; b=JTVtOf8e8sgc4hx8mXeBL4uBOaLTw66iaNgO/ou+pHqmrl4Deem+l5FUnrg6gWgfj yWRMZvZYWCMg+39S4LNL77fXDfdoX2q1FNrC0sq+tmDNLkM53Kx+0T5CLUH9aQ70aG /9AUmOTl9koneZKo3Zr0cs/y/Wm5AjHTpy9GG2yI= Feedback-ID: mattiase@acm.or Received: from smtpclient.apple (c188-150-171-209.bredband.tele2.se [188.150.171.209]) (authenticated bits=0) by mail92c50.megamailservers.eu (8.14.9/8.13.1) with ESMTP id 307CvFbZ007268; Sat, 7 Jan 2023 12:57:16 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) From: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= In-Reply-To: Date: Sat, 7 Jan 2023 13:57:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <34AFCB0F-5F53-4033-BCDF-1B3001285169@acm.org> References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> <255D9E93-422C-4A43-9876-751FDB8E61DB@acm.org> <73923B98-E4B8-44F8-9445-2FD05564ADA0@acm.org> X-Mailer: Apple Mail (2.3654.120.0.1.13) X-CTCH-RefID: str=0001.0A742F16.63B96C2E.0006, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0 X-CTCH-VOD: Unknown X-CTCH-Spam: Unknown X-CTCH-Score: 0.000 X-CTCH-Rules: X-CTCH-Flags: 0 X-CTCH-ScoreCust: 0.000 X-Origin-Country: SE X-Spam-Score: 1.0 (+) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.0 (/) 6 jan. 2023 kl. 22.41 skrev Dmitry Gutov : >> (I wish we had (byte-)compiled elisp functions carrying their own = source, either as s-exp, string of formatted source text, or source file = reference -- that would allow for sensible editing in Customise without = performance penalty. But Santa gave me a wool jumper instead, that's = nice too.) >=20 > We kind of have that already, if we just made the type for be 'sexp', = or a Lisp form. With all the freedom associated with it, just lower = performance compared to a compiled function. That's short in two respects: performance, and non-retention of = formatting and comments. We could store source refs in: - a hash table weakly keyed on the code object - some back corner of byte-code objects - OClosures We have a similar problem with regexps, which are only retained and = edited in the traditional syntax. We are veering off-topic. Sorry about that. > I'm on the fence regarding changing it, though, for compatibility and = ergonomical reasons (it's easier for the user to avoid typing a dot). Is compatibility a serious concern given that buffer-match-p is new in = 29? From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 08 Jan 2023 21:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= Cc: Philip Kaludercic , 58950@debbugs.gnu.org, Stefan Monnier Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.16732145145210 (code B ref 58950); Sun, 08 Jan 2023 21:49:02 +0000 Received: (at 58950) by debbugs.gnu.org; 8 Jan 2023 21:48:34 +0000 Received: from localhost ([127.0.0.1]:34837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pEdWr-0001Lx-Km for submit@debbugs.gnu.org; Sun, 08 Jan 2023 16:48:34 -0500 Received: from mail-wm1-f47.google.com ([209.85.128.47]:44573) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pEdWp-0001Lk-K5 for 58950@debbugs.gnu.org; Sun, 08 Jan 2023 16:48:32 -0500 Received: by mail-wm1-f47.google.com with SMTP id g19-20020a05600c4ed300b003d9eb1dbc0aso2270013wmq.3 for <58950@debbugs.gnu.org>; Sun, 08 Jan 2023 13:48:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:from:to:cc:subject:date:message-id:reply-to; bh=RWl2KwFOaO/ZrAROrChuxxClW+VlU7fKVInf84RPRRE=; b=bjvg0o0fUcEj14vC5ToeCp81tQrPyiBrBjSEpDmQ70UeZKwwzMQg79MZPNNJcXOrXs X0Jp0PsCjkKKHln+XWk9vVyVSBd5UkAJvic+QA8Krdy4kvPhAucc1Y15pAzeTMCij6rU kg/+VVOxGqrh3ZqGIbuLHUsmoPtiIuKU0EgcdpockVhfaDSNc4E8VhzG1w0cwMnRhFpv Cef67JKxupnWot7mqrTtdHL/g0pBiqs5MFXVOaCau5sHyjV7B7NTA60TxJhNLjug6UsS EU4wYMSiuTbPGng6Y2MXU5vZDrWhA2hOogg2V94m17/nzeFnOpUV45vAi+qtcjC5jy0m p6xQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :sender:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=RWl2KwFOaO/ZrAROrChuxxClW+VlU7fKVInf84RPRRE=; b=kFv1kzZFZU+Dg3Ar9UZg5YMhEBaDmMb3l+jmTpPqJ8/TPwLsTOi+g2kPuFgnKCHdU0 +qZ4sTJ8scxu7C6XPX5w1Ps+oBmhqac0CyKNOojwY6dWtOv01BaQn5h7qp6POGvFcEk+ AzYVWGVsaQF6U+eK7oMPxofXAI7MRTakNuT2h4oaW9nXDP1dRUHEtfavdZK+joJ5uTfp aBJS6+JNqMN4VtHHfRAdQND1/k5MvO4oIlj5DuXaXwMWKba61i/spBh87KOnWnnsANu9 7kWnTa2yg3Ga9WMJQnhAPkh18mZaTCbk7xroC+Wq9sDNE8G/ouc2UBHqJeU372z1saQv plGA== X-Gm-Message-State: AFqh2koF3m/eOKfRdLmvSJieMd62LAKBAzH9N1lLOt97YqWjOjkmeB5/ dPtI2hnzOMmf33dquV6NZO4= X-Google-Smtp-Source: AMrXdXtP8/ZgN0fkgzk2SBon+L1xZ+EIJfepWJor2sqZ9wLECAt1PtTd1GYy7wkXedU2VIFngrRU9A== X-Received: by 2002:a05:600c:4c21:b0:3cf:f18b:327e with SMTP id d33-20020a05600c4c2100b003cff18b327emr45279901wmp.4.1673214505552; Sun, 08 Jan 2023 13:48:25 -0800 (PST) Received: from [192.168.0.2] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f6-20020adffcc6000000b002bbdcd15e44sm3308713wrs.37.2023.01.08.13.48.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 08 Jan 2023 13:48:24 -0800 (PST) Message-ID: <268ed8c9-f56e-dc79-8e57-eeaaab98adc1@yandex.ru> Date: Sun, 8 Jan 2023 23:48:23 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Content-Language: en-US References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> <255D9E93-422C-4A43-9876-751FDB8E61DB@acm.org> <73923B98-E4B8-44F8-9445-2FD05564ADA0@acm.org> <34AFCB0F-5F53-4033-BCDF-1B3001285169@acm.org> From: Dmitry Gutov In-Reply-To: <34AFCB0F-5F53-4033-BCDF-1B3001285169@acm.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Score: -0.9 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.9 (-) On 07/01/2023 14:57, Mattias Engdegård wrote: > 6 jan. 2023 kl. 22.41 skrev Dmitry Gutov : > >>> (I wish we had (byte-)compiled elisp functions carrying their own source, either as s-exp, string of formatted source text, or source file reference -- that would allow for sensible editing in Customise without performance penalty. But Santa gave me a wool jumper instead, that's nice too.) >> >> We kind of have that already, if we just made the type for be 'sexp', or a Lisp form. With all the freedom associated with it, just lower performance compared to a compiled function. > > That's short in two respects: performance, and non-retention of formatting and comments. We could store source refs in: > > - a hash table weakly keyed on the code object > - some back corner of byte-code objects > - OClosures That's still seems like an overkill for font-lock-global-modes. And it's hard to draw a line between defcustoms which should have their own mini-languages, and those that do not. Or to look at it the other way -- perhaps the line has been drawn now, since we haven't received any further requests for extending the syntax. > We have a similar problem with regexps, which are only retained and edited in the traditional syntax. > > We are veering off-topic. Sorry about that. > >> I'm on the fence regarding changing it, though, for compatibility and ergonomical reasons (it's easier for the user to avoid typing a dot). > > Is compatibility a serious concern given that buffer-match-p is new in 29? This close to a release, it most likely is. Another compatibility goal (though probably not a hard requirement) is being able to replace project--buffer-check with the standard code, while keeping all existing user customizations in project-kill-buffer-conditions and project-ignore-buffer-conditions. The alternative would be to have a prolonged migration procedure. From unknown Tue Jun 17 22:11:46 2025 X-Loop: help-debbugs@gnu.org Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 09 Jan 2023 06:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58950 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch To: Dmitry Gutov Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Philip Kaludercic , 58950@debbugs.gnu.org Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.16732454607724 (code B ref 58950); Mon, 09 Jan 2023 06:25:02 +0000 Received: (at 58950) by debbugs.gnu.org; 9 Jan 2023 06:24:20 +0000 Received: from localhost ([127.0.0.1]:35616 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pEla0-00020W-1X for submit@debbugs.gnu.org; Mon, 09 Jan 2023 01:24:20 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53412) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pElZy-00020I-GY for 58950@debbugs.gnu.org; Mon, 09 Jan 2023 01:24:18 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 32F0A4404AD; Mon, 9 Jan 2023 01:24:13 -0500 (EST) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 7B5B6440375; Mon, 9 Jan 2023 01:24:07 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1673245447; bh=qmJG5orESEWXsLJ1Kkp9NWPXC2bhPd2zJHO4TyfMpb0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=lzjV1qvxUtZovoErLkK7/pY0ZQp4zsI7/ErJ0/jx4RDhZbrN69QWznrehwgwEmM95 IN18xYsvOb7gfuUNLmRQ85DT9jvnHRJnQFc30gTkefkberVVJ2PWyPRsxCHpHuhWyF hmE4zuywRCeimWmnO5BHgpGhNC3J0SsYPtRLWuN99sFxEl27g+S2Bhqk5EzvlCbdPL I+lchEOa8ccPWIEstSPup+4+GxQEZi+OMQmwyPwx1oCXXeP63rcOVVSnZpuKRHVMfU uPMuDVl9sa5lGeBuJ3bqYReAyAOkc9qA3EgF/f3TZS+hKo7GyArKdhbeuaAnNQUlwl eGoX14B+5+rYA== Received: from pastel (unknown [45.72.200.228]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3257A120828; Mon, 9 Jan 2023 01:24:07 -0500 (EST) From: Stefan Monnier In-Reply-To: <268ed8c9-f56e-dc79-8e57-eeaaab98adc1@yandex.ru> (Dmitry Gutov's message of "Sun, 8 Jan 2023 23:48:23 +0200") Message-ID: References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> <255D9E93-422C-4A43-9876-751FDB8E61DB@acm.org> <73923B98-E4B8-44F8-9445-2FD05564ADA0@acm.org> <34AFCB0F-5F53-4033-BCDF-1B3001285169@acm.org> <268ed8c9-f56e-dc79-8e57-eeaaab98adc1@yandex.ru> Date: Mon, 09 Jan 2023 01:24:05 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.252 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) BTW, while this is an interesting discussion, I'm not sure it matters very much. The core question is still the same: does this performance issue matter? For `display-buffer`, AFAICT we only consider a single buffer, so I can't imagine `buffer-match-p` being an important factor to the overall performance. Stefan