From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Date: Wed, 04 Jan 2023 23:31:26 -0500 Message-ID: References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="8504"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Philip Kaludercic , 58950@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 05 05:32:25 2023 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 1pDHvU-000244-Jb for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Jan 2023 05:32:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pDHvA-000553-B6; Wed, 04 Jan 2023 23:32:04 -0500 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 1pDHv8-00054q-EV for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2023 23:32:03 -0500 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 1pDHv8-0000Fo-6S for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2023 23:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pDHv7-0002AD-N7 for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2023 23:32:01 -0500 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.16728930988275 (code B ref 58950); Thu, 05 Jan 2023 04:32:01 +0000 Original-Received: (at 58950) by debbugs.gnu.org; 5 Jan 2023 04:31:38 +0000 Original-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 Original-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 Original-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) Original-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== Original-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) In-Reply-To: <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> (Dmitry Gutov's message of "Thu, 5 Jan 2023 02:00:12 +0200") 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: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:252553 Archived-At: >>>> 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