bug#51143: 29.0.50; Long delay after M-x commandname

[Michael Heerdegen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

> I remember what I had discussed with Stefan.  The uncontroversial part
> was to factor out the `commandp' tests out of
> `completion-try-completion'.
>
> I'll have a look.

This is what I have:

From 6bc974197ff3e191971f933cc7f6fd952cdbba86 Mon Sep 17 00:00:00 2001
From: Michael Heerdegen <michael_heerdegen@web.de>
Date: Sun, 18 Sep 2022 12:26:53 +0200
Subject: [PATCH] Try to speed up extended command shorthand computation

* lisp/simple.el (execute-extended-command--shorter): Compute a
complete list of `commandp' symbols once.  This significantly speeds
up complicated cases while the slowdown of simple cases is still
accetable.
---
 lisp/simple.el | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/lisp/simple.el b/lisp/simple.el
index 10a610e0c6..6724f3d6fc 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -2465,9 +2465,13 @@ execute-extended-command--shorter-1

 (defun execute-extended-command--shorter (name typed)
   (let ((candidates '())
+        commands
         (max (length typed))
         (len 1)
         binding)
+    ;; Precompute a list of commands once to avoid repeated `commandp' testing
+    ;; of symbols in the `completion-try-completion' call inside the loop below
+    (mapatoms (lambda (s) (when (commandp s) (push s commands))))
     (while (and (not binding)
                 (progn
                   (unless candidates
@@ -2480,8 +2484,8 @@ execute-extended-command--shorter
       (input-pending-p)    ;Dummy call to trigger input-processing, bug#23002.
       (let ((candidate (pop candidates)))
         (when (equal name
-                       (car-safe (completion-try-completion
-                                  candidate obarray 'commandp len)))
+                     (car-safe (completion-try-completion
+                                candidate commands nil len)))
           (setq binding candidate))))
     binding))

--
2.30.2

This speeds up computations of extended command shortcuts by a factor of
around 4 in the complicated cases, while the slowdown for the easy cases
is hardly noticeable.  Maybe Eduardo can give that a try?

Further improvements are probably not that low-hanging fruits.  The
calculation is also always interruptible so I don't think more work is
worth the trouble.

Michael.