marginalia-annotate-command-binding is slow

[minad]

This is something I observed a few times now. If I have marginalia-command-annotate-binding activated, scrolling through the list of M-x candidates is slow and lags. Scrolling through M-x is even slower than scrolling through a list of files with the marginalia-annotate-file enabled.

I did a bit of investigation and the problem is the where-is-internal function, which seems to be pretty bad. It seems to allocate a lot of memory (responsible for 70% of the allocations in the profile). This means when scrolling through the candidates the gc sets in every few lines. I find it acceptable that it sets in from time to time. This is how the gc works, not much can be done about that. But for my feeling it sets in way too often given how simple the annotator function is and given that only a handful of candidates is annotated at once. It certainly helps to increase the gc limit at the cost of longer pauses from time to time.

I am not sure what we can do - do we have to do anything? Do some caching? Rewriting the where-is-internal function and contributed to upstream if there is some potential for improvement?

Anyone else seeing this? I am on Emacs 27.1.

[oantolin]

Huh, the built-in annotation shows the key binding too. Is it also slow? Does it also use where-is-internal?

Maybe the slowdown is because of our buffer switching to show the keybindings in the previously selected buffer (instead of showing the bindings in the minibuffer)?

[minad]

Yes, it does and I think it is also slow, but I would have to recheck this. The slowdown is not due to the switching. The switching has only marginal cost (I tested without switching too). But Fwhich_key_internal is a mess, take a look at the c code. It autoloads keymaps, it can call gc, it does some internal caching etc.

[oantolin]

Probably where-is-internal, then. I just checked and read-extended-command--annotation does use it too.

[minad]

I just did the check of the Emacs 28 annotation function. It is as slow. Responsible for 94% of the allocations and 31% of the runtime when scrolling through the M-x list. I originally took the binding annotation code from Emacs 28.

[minad]

@oantolin See 1269445. Do you like that or do you think this is overdoing it? Should we add the alternative function? Given the Emacs 28 annotation behavior I am okay with showing the minibuffer bindings. Alternatively we could do caching per buffer, but I wouldn't want to make things more complicated here.

[minad]

Hash table per buffer 6567947

[oantolin]

The per buffer caching is great!

[minad]

I still wonder why it is like it is. It is astonishing that the bulk workload is so much better for the garbage collector. But as of now our annotations are both faster and more correct than the ones from Emacs 28 :)