Doom-emacs: Ivy switch buffer is slow in main workspace

[siddharthshekar]

---

Observed behavior

Running SPC b b in the main workspace produces noticeable lag. Keypresses are reflected in the minibuffer a second or so after they are pressed. For what it's, worth, I'm not sure if this is a known issue, but I don't see this when running helm instead of ivy.

Expected behavior

The lag after keypresses shouldn't be seconds-long.

Steps to reproduce

1. Have several buffers available to switch between in the main workspace.
2. Press SPC b b

System information

Click to expand

- OS: darwin (x86_64-apple-darwin18.2.0)
- Emacs: 26.1 (Feb 22, 2019)
- Doom: 2.0.9 (develop 31eb845f6b4a13ca054909c8d225da9ea3df711c)
- Graphic display: t (daemon: nil)
- System features: JPEG RSVG IMAGEMAGICK NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES THREADS LCMS2
- Details:
  elisp
  env bootstrapper: nil
  elc count: 0
  uname -a:  Darwin Siddharths-Work-MacBook-Pro.local 18.2.0 Darwin Kernel Version 18.2.0: Thu Dec 20 20:46:53 PST 2018; root:xnu-4903.241.1~1/RELEASE_X86_64 x86_64
  modules:   (:feature eval (evil +everywhere) file-templates (lookup +docsets) snippets workspaces :completion company ivy :ui deft doom doom-dashboard doom-quit evil-goggles hl-todo modeline nav-flash treemacs (popup +all +defaults) vc-gutter vi-tilde-fringe window-select :editor fold multiple-cursors rotate-text :emacs dired electric imenu term vc :tools flycheck lsp magit :lang data emacs-lisp latex markdown (org +attach +babel +capture +present +protocol) (python +pyenv) (sh +fish) :config literate (default +bindings +snippets +evil-commands) sid)
  packages:  n/a
  exec-path: (/usr/bin /bin /usr/sbin /sbin /usr/local/Cellar/emacs-plus/26.1/libexec/emacs/26.1/x86_64-apple-darwin18.2.0)

I've attached a screenshot of the profiler output on pressing SPC b b for reference:

[hlissner]

I cannot reproduce this. Could you share your buffer list? I'd like an idea of what assortment of major modes, file locations, buffer states (modified, read-only, etc), and buffer names might contribute to this slowness.

Could you also unfold more of the profiler output under ivy-rich-switch-buffer-project?

[siddharthshekar]

I invoke SPC b b and have Ctrl j pressed continuously. The scrolling is pretty bad. My apologies for not being able to reveal the full minibuffer, but I'm on a work machine right now.

[hlissner]

1. Does M-x ivy-switch-buffer suffer from this?
2. How about M-x counsel-switch-buffer?
3. Does this help:

;; in ~/.doom.d/config.el
(advice-add #'+ivy-rich-buffer-name :override #'identity)

[siddharthshekar]

1. ivy-switch-buffer does suffer from this.
2. counsel-switch-buffer is fast and responsive.
3. Adding that advice didn't really help.

[nxtk]

i maybe missing something but have you tried those?
(setq which-key-idle-delay 0.1
which-key-idle-secondary-delay 0.1)

Because i also noticed that, and above fixed it for me.

[siddharthshekar]

@NXTk, I'm not sure if it's related to which-key. In any case, changing those settings didn't work for me.

[hlissner]

@siddharthshekar Do you have (setq +ivy-buffer-preview t) in your config?

Or do you have any remote (tramp) buffers open?

EDIT: Also, does this help?

(after! ivy
  (setq ivy-switch-buffer-faces-alist nil)
  (ivy-set-display-transformer 'internal-complete-buffer nil))

[siddharthshekar]

I haven't changed +ivy-buffer-preview myself and it's set to nil. I also don't have any tramp buffers open.

I tried out the snippet you provided but no dice. I've been running on the same workspace session for the last several days so I'll try starting a brand new session and see if I can reproduce this issue.

[siddharthshekar]

Update: Still seeing this issue. I looked around a little bit and perhaps this is a related issue?

[hlissner]

That does look related, but they haven't figured out the cause yet.

While we wait for a fix (or I find an interim solution), a simple workaround could be to disable ivy-rich:

;; place in ~/.doom.d/config.el
(remove-hook 'ivy-mode-hook #'ivy-rich-mode)

[hek14]

I also met this problem when I tried to open 'remote' files in OSXFUSE volumes.
In my case, counsel-switch-buffer became fast and smooth after doom-dashboard was removed. But this didn't fix the ivy-switch-buffer.

[hlissner]

Is this still an issue?

[rgrinberg]

I can reproduce the slowness and it's essentially the fault of ivy-rich and/or projectile. The gist of it is that projectile-name is slow and that ivy-rich calls it for every single buffer.

[siddharthshekar]

I still see this happening, but I've altered my workflow to a) just staying in the appropriate workspace for the most part, and b) typing out the first few characters of the buffer I want to switch to if I'm in the main workspace.

[CThuleHansen]

Just to note that I am experiencing this issue as well on mac.
Experiencing the same:

• ivy-switch-buffer does suffer from this.
• counsel-switch-buffer is fast and responsive.

EDIT Currently Upgrading and updating. Thanks for the announcements on discord!
EDIT2 Much faster with newest version! thank you.

[EtiamNullam]

This looks like I'm facing similar problem on Windows now as @siddharthshekar - massive slowdown when holding ctrl+j or down arrow key. Luckily with (ivy +fuzzy) its not as painful.

If you "tap" buttons instead of holding them down its much better, but when you hold button down it looks like on that gif: https://user-images.githubusercontent.com/1447996/55842299-b7da6800-5ae7-11e9-8863-18d29ea8a562.gif

You might want to check the issue I linked above for more info.

[haji-ali]

See a possible workaround here: https://github.com/Yevgnen/ivy-rich/issues/87#issuecomment-689581896_

[cvanelteren]

I am still experiencing huge slow downs similar to described above. Workaround by @haji-ali does not improve the issue.