Performance issue when the which menu is shown

[dindon-sournois]

Description

Performance issue related to which-key--replace-in-repl-list-many. At some
point any emacs command will take about 10 seconds to complete. Increasing the
value of dotspacemacs-which-key-delay significantly seems to hide the issue so
it seems what really takes time is to show the which buffer. Any help to
figure what is hapenning is welcome.

Reproduction guide 🪲

• Start working with Emacs

Observed behaviour: 👀 💔

• At some point any action will take several seconds (even just switching buffer)
• Performance issue sometimes resolves itself or forces me to restart emacs

Expected behaviour: ❤️ 😄

• Normal performance, obviously

System Info 💻

• OS: gnu/linux
• Emacs: 26.3
• Spacemacs: 0.300.0
• Spacemacs branch: develop (rev. 346be15)
• Graphic display: nil
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(helm
 (ibuffer :variables ibuffer-group-buffers-by 'modes))

• System configuration features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB NOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM MODULES THREADS LIBSYSTEMD LCMS2

Profiling trace 🐾

I started the profiling as soon as the issue arised. I did a few
evil-window-left and evil-window-right which took about 10 seconds each.

- timer-event-handler                                           30216  98%
 - apply                                                        30213  98%
  - which-key--update                                           29631  96%
   - which-key--create-buffer-and-show                          29631  96%
    - which-key--get-bindings                                   29039  94%
     - which-key--format-and-replace                            28906  93%
      - which-key--maybe-replace                                28718  93%
       - apply                                                  28538  92%
        - which-key--replace-in-repl-list-many                  28500  92%
           which-key--match-replacement                           313   1%
       + which-key--get-pseudo-binding                            180   0%
      + kbd                                                        75   0%
      + which-key--propertize-description                          29   0%
        which-key--extract-key                                      7   0%
        which-key--propertize-key                                   3   0%
      + which-key--maybe-add-docstring                              3   0%
     + which-key--get-current-bindings                            116   0%
     + sort                                                         7   0%
    + which-key--create-pages                                     575   1%
    + which-key--show-page                                         17   0%
  + helm-ff--cache-mode-refresh                                   518   1%
  + sp-show--pair-function                                         23   0%
  + savehist-autosave                                              15   0%
  + evil-ex-hl-do-update-highlight                                  4   0%
   timerp                                                           3   0%
+ command-execute                                                 251   0%
+ redisplay_internal (C function)                                 144   0%
+ ...                                                             125   0%
+ evil-visual-post-command                                          9   0%
+ which-key--hide-popup                                             7   0%
+ evil-activate-visual-state                                        5   0%
  internal-echo-keystrokes-prefix                                   3   0%
+ xterm-mouse-translate-extended                                    3   0%
+ evil-esc                                                          3   0%
+ evil-repeat-pre-hook                                              3   0%

[dindon-sournois]

Actually it seems to be a known issue on which-key, looking at this (even if it's still unsure how it happens). Closing the issue, sorry for the trouble!

[bitclick]

This is not simply an upstream bug, but a result of how which-key is used by spacemacs. I think this should be open to raise awareness among spacemacs developers, that which-key offers another way of setting up the descriptions which does not suffer from performance issues.

see here
justbur/emacs-which-key#226 (comment)

here
justbur/emacs-which-key#226 (comment)

and here
justbur/emacs-which-key#261 (comment)

[thanhvg]

Can you delete your epla folder then restart spacemacs so a fresh install of latest packages will kick in?

If your emacs version is 26.3 then the default elpa folder is ~/.emacs.d/elpa/26.3. Since you only have two layers enabled, there is no way which-key would struggle like that imo.

[dindon-sournois]

Hey @thanhvg. I've deleted my elpa folder. It seems I can't reproduce the issue. I've added more layers but still couldn't not reproduce anymore (which is good news for me I guess). I'm now trying with emacs 27.1 with a fair amount of layers activated, but it seems I don't have the issue.

Why would deleting elpa folder fix the issue?

[vv111y]

@thanhvg as @bitclick posted above, upstream has a solution, but it does require code rewrite in spacemacs to implement their new function.
I would be willing to help in any way I can. I looked at spacemacs relevant code and it is not a quick solution.
For the new function you need to specifically pair up each key-chord and it's description.
If I understand which-key-replacement-alist correctly, these are rules being applied. With the new function means these cannot be used, except to generate explicit key and def cons pairs.

[bitclick]

I'm now trying with emacs 27.1 with a fair amount of layers activated, but it seems I don't have the issue.

Yes, i can confirm the same for me. Seems like emacs27.1 is just way faster than 26.3 (where which-key was not usable with default settings) While i think the new api of which-key is objectively better, for me it is less of a priority now.

[vv111y]

hmmm. emacs27.1 has an orgmode bug that I wanted to avoid. Maybe it's fixed by now.
Wonder how come it's faster.

[thanhvg]

@vv111y thanks for the tip, here is my first try with the new api #14141

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Please let us know if this issue is still valid!