From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#58839: [Patch] Re: bug#58839: 29.0.50; project-kill-buffer fails when Eglot is running Date: Wed, 02 Nov 2022 08:21:41 +0000 Message-ID: <877d0dbwbu.fsf@posteo.net> References: <87sfj8umwb.fsf@posteo.net> <87wn8invbx.fsf@posteo.net> <877d0iw8iq.fsf@gmail.com> <837d0hhlke.fsf@gnu.org> <46ff0065-5645-ef1e-2621-242fb6a73f98@yandex.ru> <87v8o0uxn5.fsf@gmail.com> <787a4362-7ff5-7dbb-9118-16e4bee5f328@yandex.ru> <87edunvhf2.fsf@gmail.com> <6d4d9e72-1bae-4d64-b7c1-c2b9c11e396f@yandex.ru> <87tu3jgdbv.fsf@posteo.net> <87h6zihq3q.fsf@posteo.net> <877d0ehlnb.fsf@posteo.net> <87edumg4fd.fsf@posteo.net> <874jvig2rp.fsf@posteo.net> <87edulu8ly.fsf@gmail.com> <87wn8dbyq1.fsf@posteo.net> <871qqlu79b.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16011"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 58839@debbugs.gnu.org, Dmitry Gutov To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 02 09:22:16 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oq90p-0003vp-F8 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 02 Nov 2022 09:22:15 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oq90e-0004iF-VY; Wed, 02 Nov 2022 04:22:04 -0400 Original-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 1oq90d-0004i8-GZ for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:22:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oq90c-0001j5-O6 for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:22:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oq90c-0002L4-7c for bug-gnu-emacs@gnu.org; Wed, 02 Nov 2022 04:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 02 Nov 2022 08:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 58839 X-GNU-PR-Package: emacs Original-Received: via spool by 58839-submit@debbugs.gnu.org id=B58839.16673773118973 (code B ref 58839); Wed, 02 Nov 2022 08:22:02 +0000 Original-Received: (at 58839) by debbugs.gnu.org; 2 Nov 2022 08:21:51 +0000 Original-Received: from localhost ([127.0.0.1]:44867 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq90Q-0002Kf-T6 for submit@debbugs.gnu.org; Wed, 02 Nov 2022 04:21:51 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]:57453) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oq90O-0002KS-NL for 58839@debbugs.gnu.org; Wed, 02 Nov 2022 04:21:49 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id E7A69240106 for <58839@debbugs.gnu.org>; Wed, 2 Nov 2022 09:21:42 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1667377302; bh=8rGBLeQTatMLtFtWVAm9WzySkujMKY8TW358ZcjpmpY=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=Dw2Bc27/VA8pE1DGV/Izx05CYu1FUszuE8XkW3xLF5OzP1S+e0T2abliNi3F4CjaS eIPEbpICd2ujMkJIkXXAwp1v1WNAa8W1KGYT8e8zTFBFn4WqKzkaA39A8Ui2vLgaup SwvyjmkbjqDQi/SJcHMwVRGVWSqYI5a9YKxQMmonjffA8Sd5D9VA8D2MoDcfn7pP7E 76yYAG1OreytGY5NnQ5j5spKGDCaBHcJ7Ap5qk/ffq0LTb/ta8YoWmGDzeAVI5Lwqr buCGe19DYtzAGPnrby/Q0sBBpoF7lZe6spoh1umZOmuuS9sOvnRgPlXXA12eg6hbMe FQJ/6sI1NdFgg== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4N2Kc60nB9z6tmy; Wed, 2 Nov 2022 09:21:41 +0100 (CET) In-Reply-To: <871qqlu79b.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Wed, 02 Nov 2022 07:48:16 +0000") 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 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: "bug-gnu-emacs" Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:246848 Archived-At: Jo=C3=A3o T=C3=A1vora writes: > Philip Kaludercic writes: > >> Jo=C3=A3o T=C3=A1vora writes: >> >>> Philip Kaludercic writes: >>> >>>>> Yes, do that, but use byte-compile instead, not eval. >>>> I have tried both, and it doesn't appear to be a particular advantage >>>> one way or another. That being said, this approach is *a lot* faster, >>>> to the point that I first assumed it was broken: >>> >>> Yes, this approach is always going to be much faster than the "naive" >>> approach. Now I've taken your code as a starting point, simplified it, >>> and I get a reasonable/typical 3.5x speedup when I use a >>> byte-compilation strategy, so one of us isn't measuring >>> >>> ```elisp >>> (defun translate-buffer-condition-1 (condition) >>> (pcase-exhaustive condition >>> ((or 't 'nil) >>> condition) >>> ((pred stringp) >>> `(string-match-p ,condition (buffer-name buffer))) >>> ((pred functionp) >>> `(,condition buffer)) >> >> This would break the current behaviour, because `buffer-match-p' >> requires the function be called with an additional argument if possible. >> >> This is fundamental for `display-buffer-alist' to work. > > I couldn't figure out where this argument arise or who should provides > it (the condition?). It wasn't clear. At any rate, if you understand > this you can probably re-add it and I'm sure it won't make any > difference to the time. See `display-buffer-assq-regexp' in window.el. >>> (`(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 ,(translate-buffer-condition-1 cond))) >>> (`(or . ,conds) >>> `(or ,@(mapcar #'translate-buffer-condition-1 conds))) >>> (`(and . ,conds) >>> `(and ,@(mapcar #'translate-buffer-condition-1 conds))))) >>> >>> (defun translate-buffer-condition (condition) >>> `(lambda (buffer) ,(translate-buffer-condition-1 condition))) >>> >>> (defvar sample-condition >>> '(and (or buffer-file-name >>> (derived-mode . compilation-mode) >>> (derived-mode . dired-mode) >>> (derived-mode . diff-mode) >>> (derived-mode . comint-mode) >>> (derived-mode . eshell-mode) >>> (derived-mode . change-log-mode)) >>> "\\*.+\\*" >>> (not . "\\` "))) >>> >>> (defvar form (translate-buffer-condition sample-condition)) >>> (defvar compiled (byte-compile form)) >>> >>> (benchmark-run 100000 (funcall (eval form) (current-buffer))) ;; (0.397= 404883 3 0.18942550900000032) >>> (benchmark-run 100000 (funcall compiled (current-buffer))) ;; (0.113651= 836 0 0.0) >>> ``` >>> >>> I couldn't understand the need for a hash table or special symbol vars >>> or what that "arg" was, so I took it out, but it shouldn't make a >>> difference. >> >> The hash table makes a significant different, try evaluating >> >> (benchmark-run 100000 (funcall (byte-compile compiled) (current-buffe= r))) ;; (0.113651836 0 0.0) >> > > You seem to be suggesting to byte-compile a compiled object which is > odd. Did you mean (byte-compile form)?=20=20 Yes, that was a copy-o on my end. > More importantly, you're > forcing the byte-compilation process to run every one of those 100000 > repetitions, which is not something we want to measure: the point of any > code compilation is to do it once and then reuse the results of > compilation many times. Exactly, but if the byte-compilation would take place in buffer-match-p, then the measurement is relevant. > (and I'm still confused by the purpose of the hash table usage) The rationale is the same as for regular expressions in the core. They are also compiled and stored, to avoid the need for them to be interpreted over and over again. This should all be explained in the bug report I pointed you to, and where this discussion should continue. >> The fresh symbols are used to keep the code clean and avoid possible >> naming conflicts. > > Can you explain what naming conflict would arise or how the code I > provided is somehow unclean? This is currently not the case, but if the language extended in the future, there is the possibility that naming conflicts could arise. I am just following the same principle used when writing macros that avoids name capturing.