From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Kangas Newsgroups: gmane.emacs.bugs Subject: bug#50599: [PATCH] Don't recommend against "\[...]" substitutions for performance Date: Wed, 15 Sep 2021 09:11:02 +0200 Message-ID: References: <83v932bawy.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16074"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50599@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Sep 15 09:12:12 2021 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 1mQP5Y-0003wW-1d for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Sep 2021 09:12:12 +0200 Original-Received: from localhost ([::1]:55002 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mQP5V-0005Lp-Sh for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Sep 2021 03:12:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52380) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mQP5N-0005Js-UL for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 03:12:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:39144) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mQP5N-0001zc-MF for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 03:12:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mQP5N-0004sf-IG for bug-gnu-emacs@gnu.org; Wed, 15 Sep 2021 03:12:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Kangas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Sep 2021 07:12:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50599 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 50599-submit@debbugs.gnu.org id=B50599.163168988118715 (code B ref 50599); Wed, 15 Sep 2021 07:12:01 +0000 Original-Received: (at 50599) by debbugs.gnu.org; 15 Sep 2021 07:11:21 +0000 Original-Received: from localhost ([127.0.0.1]:50690 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQP4j-0004rm-7R for submit@debbugs.gnu.org; Wed, 15 Sep 2021 03:11:21 -0400 Original-Received: from mail-pj1-f52.google.com ([209.85.216.52]:55068) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mQP4i-0004rX-2o for 50599@debbugs.gnu.org; Wed, 15 Sep 2021 03:11:20 -0400 Original-Received: by mail-pj1-f52.google.com with SMTP id i19so1473404pjv.4 for <50599@debbugs.gnu.org>; Wed, 15 Sep 2021 00:11:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rDi0mzCmHSEZftNq893FbzFgv2hisaH5b8Fb8zNH3d0=; b=til4D92/dkRbp80eOYujGUd9k0vfX8Gl10hQ+VtgJV9gER7Fn1RrwqAIYbB1zI6qZ1 QeL7em2a61CunutY4l+5cOG4ss3yQlnMaoAg2rFURcYhc/HudV/DQACZ2m8ROdwTD7kV UTVU+45T7UR2rJ3bGG8676JRMWKDy2nr1Q35g/99vXMxhzc5CRtTSFJUOFFap+BkW0NW raz/y/q/jLs2KS+Ti3YKDIai4md/PDSkxoLyQNOoTH/8uP5EWKgW4APD0gdU8M8fLjav jkH66dz5vA8cbsgnOlMbOmMOpx1rDt14hFTTgc4z+5QnUVtNLWY17EH32umkxjbmJvEi PBjw== X-Gm-Message-State: AOAM530wC40cNVFVssj8rypWlXFb8I1Xq8PE3+Ax43eJJZsM/yDgHzgL cwL191hO0XBYBV1/2YYGyeEQ87DMXhbzKVYR1UX2aZUZ42k= X-Google-Smtp-Source: ABdhPJxlVBIU0PfjFqcszrnDRlsVFiguFF3+8HowRQJ9nhsA+38bh59yXTHw2sfFXNHk0jgBrY7Gge1fQR3pw2NAeH0= X-Received: by 2002:a17:90b:3805:: with SMTP id mq5mr6106843pjb.143.1631689874110; Wed, 15 Sep 2021 00:11:14 -0700 (PDT) In-Reply-To: <83v932bawy.fsf@gnu.org> 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" Xref: news.gmane.io gmane.emacs.bugs:214363 Archived-At: Eli Zaretskii writes: > Thanks for the research, but the removal you propose is too radical. > The text already says "very many times". You are saying that on your > system (which has what CPU, btw?) "very many" is a very large number, > but even for you 1000 references takes 50 msec, which begins to be > significant. According to /proc/cpuinfo, machine has a Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz. I believe this CPU was first released in 2013, and if I'm not mistaken was not on the high-end even then. Anything up to 100ms is perceived as instantaneous, so 50ms is still very fast. Note in particular that I only came up with the this result by copying one of our longest docstrings 10 times over. Even the longest docstrings we have in Emacs will still be displayed under 10ms, so let's please use that figure as the basis for this discussion. > So I'm okay with somehow modifying the text to provide a better idea > of what "very many" means nowadays, but I think the advice is still > valid and shouldn't be removed. We cannot guarantee that arbitrarily > large number of such references will not slow down help display. Formally, it is correct that if you throw very large inputs at `substitute-command-keys', you will start to notice performance issues. But when evaluating performance considerations we must also consider what inputs we will realistically expect to see. Even in `ibuffer-mode', which already has a very large number of substitutions (107), this takes only 5ms on my machine. It is in my opinion unrealistic to expect that there exist more than a handful modes out there that has more than an order of magnitude more commands than this one. You will start running out of keys, the docstring will be completely unwieldy, etc., etc. If there exists any highly extreme outliers out there for which this might (!) become a problem, it is only because they are doing something silly like writing major modes with 2000+ commands in them. If they would come to emacs-devel with this problem I expect that we would tell them "then don't do that". But this advice is completely irrelevant for everyone else, and only wastes valuable space in the reference manual.