Consider removing project information by default
rgrinberg opened this issue · comments
Projectile information is quite useful, but the functions to get the project root can be quite slow. It would be great to have a mode to disable the projectile interaction.
In addition, the following field makes ivy-rich drastically slower:
(ivy-rich-switch-buffer-project (:width 15 :face success))
While it's a useful field, it should not be in the default list of fields if it has such bad performance characteristics.
Hi, how many project buffers are you using when you feel slow? Are you working with tramp?
I generally open about 300~500 buffers on my MacBook 2014 and don't feel any laggy though. The scrolling is still fluent enough in most (99.5% I think) cases.
(Note that the gif is missing frames and 'looks laggy'.)
Remote buffer parsing may be slow if you are having a slow tramp connection. But ivy-rich-parse-remote-buffer and ivy-rich-parse-remote-file-path may be set to nil to ignore remote buffers.
Also could you provide the detail result of profiling?
Hi, almost all the buffers you have opened seem to belong to a project. This is indeed the fast path for projectile.
Hi, how many project buffers are you using when you feel slow?
I observe the slowness to be proportional to number of buffers without projects * how nested are the paths on the file system. When you have 50 such buffers open you will surely notice it. Go to /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include and open about 50 header files. You should observe the slowness.
Are you working with tramp?
I do not use tramp at all because it's too slow.
Also could you provide the detail result of profiling?
Sure, will do so.
With the default value of projectile-project-root-files-functions, it's a very little bit slower with 150 of such buffers, but still quite fast. But anyway, the idea
Only when the file path of the buffer wasn't known it was necessary to get the projectile root.
should help to improve performance.
I don't know to make a fancy gif, but here are my profiler results for a single call of ivy-switch-bufffer with around 50 buffers :)
For comparison, in my PR the cost projectile is barely registered by the profiler.
- command-execute 1219 96%
- call-interactively 1219 96%
- funcall-interactively 1219 96%
- ivy-switch-buffer 1217 96%
- ivy-read 1217 96%
- apply 1217 96%
- #<compiled 0x40507ccd> 1217 96%
- read-from-minibuffer 1166 92%
- ivy--queue-exhibit 1144 90%
- ivy--exhibit 1144 90%
- ivy--format 1144 90%
- mapcar 1143 90%
- ivy-rich--ivy-switch-buffer-transformer 1143 90%
- ivy-rich-format 1143 90%
- mapconcat 1143 90%
- #<compiled 0x45fae891> 1143 90%
- ivy-rich-format-column 1143 90%
- ivy-rich-switch-buffer-project 888 70%
- ivy-rich-switch-buffer-in-project-p 888 70%
- projectile-project-name 888 70%
- projectile-project-root 888 70%
- cl-some 888 70%
- #<compiled 0x45f94691> 888 70%
+ projectile-root-top-down 635 50%
+ projectile-root-bottom-up 109 8%
+ file-truename 95 7%
+ projectile-root-top-down-recurring 48 3%
- ivy-rich-switch-buffer-path 255 20%
- ivy-rich--switch-buffer-root-and-filename 255 20%
- ivy-rich-switch-buffer-in-project-p 255 20%
+ projectile-project-name 255 20%
+ #<compiled 0x404cde6d> 14 1%
+ minibuffer-inactive-mode 2 0%
+ timer-event-handler 2 0%
+ ivy--reset-state 25 1%
+ profiler-report 2 0%
+ timer-event-handler 42 3%
+ redisplay_internal (C function) 2 0%
+ global-font-lock-mode-check-buffers 1 0%