bug#50599: [PATCH] Don't recommend against "\[...]" substitutions for performance

[Stefan Kangas]

Eli Zaretskii <eliz@gnu.org> 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.