Re: Caching where-is-internal (was: (icomplete-vertical-mode): Add support for affixations and, annotations)

[Daniel Mendler]

On 5/24/21 6:22 PM, Stefan Monnier wrote:
> `where-is-internal` is supposed to do its own caching already (I added
> that around the time of Emacs-21 because it was making construction of
> the menubar too slow).  So if you see problems on that side, please
> report them.

I think the problem was that `where-is-internal` can generate a lot of
garbage memory. In Marginalia we have this code:

~~~
(defun marginalia-annotate-binding (cand)
  "Annotate command CAND with keybinding."
  ;; Precomputing the keybinding of every command is faster than
  ;; looking it up every time using `where-is-internal'.
  ;; `where-is-internal' generates a lot of garbage, leading to
  ;; garbage collecting pauses when interacting with the minibuffer.
  ;; See https://github.com/minad/marginalia/issues/16.
  (unless marginalia--annotate-binding-hash
    (setq marginalia--annotate-binding-hash
          (make-hash-table :size 1025))
    (mapatoms
     (lambda (sym)
       (when-let (key (and (commandp sym)
                           (where-is-internal sym nil t)))
         (puthash sym key marginalia--annotate-binding-hash)))))
  (when-let* ((sym (intern-soft cand))
              (binding (gethash sym marginalia--annotate-binding-hash)))
    (propertize (format " (%s)" (key-description binding))
                'face 'marginalia-key)))
~~~

But I cannot tell you much about the exact reasons. It just turned out
that calling `where-is-internal` once on all symbols was faster than
calling it occasionally.

In Vertico/Selectrum etc, the `marginalia-annotate-binding` function is
called for each candidate and the difference was noticeable when
scrolling through the candidate list.

The funny thing here is that the initial (costly?) computation of the
`marginalia--annotate-binding-hash` does not lead to a noticeable slowdown.

Daniel