GNU bug report logs - #50599
[PATCH] Don't recommend against "\[...]" substitutions for performance

Previous Next

Package: emacs;

Reported by: Stefan Kangas <stefan <at> marxist.se>

Date: Wed, 15 Sep 2021 06:29:02 UTC

Severity: minor

Tags: patch

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


Message #14 received at 50599 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 50599 <at> debbugs.gnu.org
Subject: Re: bug#50599: [PATCH] Don't recommend against "\[...]" substitutions
 for performance
Date: Wed, 15 Sep 2021 11:24:14 +0300
> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Wed, 15 Sep 2021 09:11:02 +0200
> Cc: 50599 <at> debbugs.gnu.org
> 
> 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.

Your machine is quite fast, even though it's 8 years old.  (Mine is 9
years old, and is faster.)  There are many machines in use out there
that are much, much slower.

> > 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.

We have no idea what could Lisp programmers out there want to do with
this.  For example, I could envision some programmatically generated
help text with many such references.  Where there are limitations due
to the implementation, we should strive to let people know about them.

> But this advice is completely irrelevant for everyone else, and only
> wastes valuable space in the reference manual.

I disagree with the "completely irrelevant" part, the general advice
to keep the use of \\[..] to the minimum is still valid, so deleting
that text entirely throws away the baby together with the bathwater.
We should adapt the text to modern CPUs without losing the basic idea.




This bug report was last modified 3 years and 252 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.