unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Kangas <stefan@marxist.se>
Cc: 50599@debbugs.gnu.org
Subject: bug#50599: [PATCH] Don't recommend against "\[...]" substitutions for performance
Date: Wed, 15 Sep 2021 11:24:14 +0300	[thread overview]
Message-ID: <83tuimb61d.fsf@gnu.org> (raw)
In-Reply-To: <CADwFkm=aYOvhdJynONdUfXNDc41=RBWEunpn_=bznZvhgCruJQ@mail.gmail.com> (message from Stefan Kangas on Wed, 15 Sep 2021 09:11:02 +0200)

> From: Stefan Kangas <stefan@marxist.se>
> Date: Wed, 15 Sep 2021 09:11:02 +0200
> Cc: 50599@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.





  reply	other threads:[~2021-09-15  8:24 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-15  6:27 bug#50599: [PATCH] Don't recommend against "\[...]" substitutions for performance Stefan Kangas
2021-09-15  6:38 ` Eli Zaretskii
2021-09-15  7:11   ` Stefan Kangas
2021-09-15  8:24     ` Eli Zaretskii [this message]
2021-09-15 14:13       ` Stefan Kangas
2021-09-15 15:41         ` Eli Zaretskii
2021-09-15 18:37           ` Stefan Kangas
2021-09-15 19:03             ` Eli Zaretskii
2021-09-16 14:08               ` Lars Ingebrigtsen
2021-09-15 15:46         ` bug#50599: [External] : " Drew Adams

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83tuimb61d.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=50599@debbugs.gnu.org \
    --cc=stefan@marxist.se \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).