From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#58950: [PATCH] * lisp/subr.el (buffer-match-p): Optimise performance Date: Thu, 5 Jan 2023 02:00:12 +0200 Message-ID: <1119f0ff-aacf-b41e-e7f7-b0a00132b35f@yandex.ru> References: <875yfyebi0.fsf@posteo.net> <87a6331xts.fsf@posteo.net> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31697"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.4.2 Cc: 58950@debbugs.gnu.org To: Philip Kaludercic , Mattias =?UTF-8?Q?Engdeg=C3=A5rd?= , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jan 05 01:01:31 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 1pDDhL-00080a-2g for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 05 Jan 2023 01:01:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pDDgx-0004fr-Sr; Wed, 04 Jan 2023 19:01:07 -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 1pDDgs-0004fB-Ol for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2023 19:01:02 -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 1pDDgs-0006XE-G5 for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2023 19:01:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pDDgs-0000wE-6c for bug-gnu-emacs@gnu.org; Wed, 04 Jan 2023 19:01:02 -0500 X-Loop: help-debbugs@gnu.org 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 Original-Received: via spool by 58950-submit@debbugs.gnu.org id=B58950.16728768223535 (code B ref 58950); Thu, 05 Jan 2023 00:01:02 +0000 Original-Received: (at 58950) by debbugs.gnu.org; 5 Jan 2023 00:00:22 +0000 Original-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 Original-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 Original-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) Original-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) Content-Language: en-US In-Reply-To: <87a6331xts.fsf@posteo.net> 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:252548 Archived-At: 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?