helm-projectile-find-file is slow

[eipplusone]

helm-projectile-find-file used to be very snappy once the indexing has been done, now it takes about a second and a half on every invocation. It's a small project, just a handful of files. It almost feels like it tries to index every time I invoke the function.

I'm on develop branch. No projectile-related personal configs. It persists after I invalidate the cache.

[eipplusone]

I've started from scratch spacemacs and it works as expected - something's wrong with my config.

[eipplusone]

The reason the above helped is it cloned the master branch by default. The moment I switched to develop the problem came up again.

[cpaulik]

Which OS are you using? There were some changes to projectile caching defaults in develop. See #3802

[StreakyCobra]

Which OS are you using?

Pasting the result of SPC h d s here would be helpful :-)

[tuhdo]

On master, it is fast because caching is enabled. On develop, it is slow because if your project is large, you must wait until Git finish retrieve the file list, and then Projectile processes the file list every single time helm-projectile-find-file is called. It takes several seconds or more on a large project (i.e. project with 10k files). With caching, those steps are skipped because the file list is reused from the saved file list.

How many files are there in your project?

[eipplusone]

@cpaulik looked at that, I'm using Mac OS, and if I understand correctly the alien stuff is Windows related.

@StreakyCobra

System Info

• OS: darwin
• Emacs: 24.5.1
• Spacemacs: 0.104.8
• Spacemacs branch: master (rev. 44d4525)
• Distribution: spacemacs
• Layers:

((auto-completion :variables auto-completion-enable-help-tooltip t auto-completion-enable-sort-by-usage t auto-completion-enable-snippets-in-popup t)
 better-defaults emacs-lisp git markdown org sql
 (shell :variables shell-default-height 30 shell-default-position 'bottom shell-default-shell 'ansi-term)
 syntax-checking version-control ruby vagrant javascript spotify ycmd python semantic java go clojure chrome yaml jabber xkcd dash deft scala themes-megapack)

I have switched back to master branch because of the issue.

@tuhdo it takes about the same amount of time regardless of the project size.

If it's of any help, here are my projectile and helm projectile versions:

projectile-20151130.1039
helm-projectile-20151021.248

[eipplusone]

@tuhdo if that's the case, could it be that it's my Git that is slow and slowing projectile down? I could try running the git command that projectile is using and see if that comes back slow.

[tuhdo]

@voltecrus Yes, Projectile can only go as fast as Git goes. If your Git project is large, a delay is expected and that's why we enable cache for Projectile.

[zilongshanren]

@voltecrus @tuhdo
I have switched to ivy-mode and the performance is very good.

you could refer to this link https://github.com/abo-abo/swiper for more information.

I use (global-set-key (kbd "C-x C-f") 'counsel-find-file) for finding files.

[tuhdo]

I usually work with projects with thousands of files, or many of ten thousands of files, and Projectile works great for me. On small projects, i.e. just thousands of files, it usually takes instant for me to get the file list. For large project (i.e. 30k files), I use caching, and the first time only takes a few seconds.

@zilongshanren Counsel lacks many features that I need i.e. switch to other files in a large project, without any configuration, or go to any file at point, even without full path.

[fishtreesugar]

I met this situation when I input the capital letter.

env:

• OS: darwin
• Emacs: 24.5.1
• Spacemacs: 0.105.4
• helm-20160101.1239
• projectile-20160103.1010

[patrickt]

I too am seeing this.

OS: Darwin
Emacs: 25.0
Spacemacs: 0.105.9
helm: 20160126.1110
projectile: 20160124.940

[eipplusone]

Seeing this again after an upgrade to 105 release on the master branch.

System Info

• OS: darwin
• Emacs: 24.5.1
• Spacemacs: 0.105.11
• Spacemacs branch: master (rev. 93e55bb)
• Distribution: spacemacs
• Editing style: hybrid
• Completion: helm
• Layers:

((auto-completion :variables auto-completion-enable-sort-by-usage t auto-completion-enable-snippets-in-popup t)
 better-defaults emacs-lisp spell-checking git markdown restclient org sql
 (shell :variables shell-default-height 30 shell-default-position 'bottom shell-default-shell 'ansi-term)
 syntax-checking version-control ruby vagrant javascript spotify ycmd python semantic java go clojure chrome yaml jabber xkcd dash deft scala themes-megapack dockerfile)

i.e. it seem to have leaked from the develop branch into master...

[eipplusone]

So the offender is this function:

(defun projectile-current-project-files ()
  "Return a list of files for the current project."
  (let ((files (and projectile-enable-caching
                    (gethash (projectile-project-root) projectile-projects-cache))))
    ;; nothing is cached
    (unless files
      (when projectile-enable-caching
        (message "Empty cache. Projectile is initializing cache..."))
      (setq files (-mapcat #'projectile-dir-files
                           (projectile-get-project-directories)))
      ;; cache the resulting list of files
      (when projectile-enable-caching
        (projectile-cache-project (projectile-project-root) files)))
    (projectile-sort-files files)))

In particular, since caching has been disabled, it has to get the list of files every time here:

(setq files (-mapcat #'projectile-dir-files
                           (projectile-get-project-directories))

I looked at the issue #3802 and the mentioned reddit thread, but I couldn't find anything that would relate to the code above breaking.

[eipplusone]

In other words, the way I understand it, the reddit thread is wrong. Since projectile-enable-caching is nil and there's nothing in the projectile-projects-cache no caching is used at all, which does break the functionality.

Meanwhile if you have this problem putting (setq projectile-enable-caching t) in you dotfile fixes it.

[ak1394]

Same as fishtreesugar comment above, the search in helm-projectile-find-file seems very slow when I start search with certain uppercase char ("Q"), some other uppercase chars seem fine. Lowercase "q" is fine as well.

System Info

• OS: darwin
• Emacs: 24.5.1
• Spacemacs: 0.105.20
• Spacemacs branch: master (rev. 9c7250a)
• Graphic display: t
• Distribution: spacemacs
• Editing style: vim
• Completion: helm
• Layers:

(javascript react shell python org html)

[EMayej]

Maybe that slow is related to default shell.

I had a lot of plugins in zsh(oh-my-zsh). When I run emacs with zsh as my default shell, helm-projectile-find-file runs with a noticeable delay.
After I switch back to vanilla bash, helm-projectile-find-file responds instantly with my small project.

I tried to searching code in projectile, but not find anything involving shell invoking. Maybe I'm wrong about this.

Anyway, just another option you guys can have a look.

[chriswilding]

I can corroborate @EMayej's experience. When using zsh/oh-my-zsh with spacemacs I'm experiencing a very noticeable delay when helm-projectile-find-file runs. Switching to bash results in helm-projectile-find-file responding match faster.

System Info

OS: darwin
Emacs: 24.5.1
Spacemacs: 0.105.22
Spacemacs branch: master (rev. 9f9faa4)
Graphic display: nil
Distribution: spacemacs
Editing style: vim
Completion: helm
Layers:

(auto-completion better-defaults dash elixir emacs-lisp erlang git github html javascript latex markdown org python react
                 (ruby :variables ruby-version-manager 'rbenv)
                 rust
                 (shell :variables shell-default-height 30 shell-default-position 'bottom)
                 spell-checking sql swift syntax-checking version-control vinegar yaml)

[chriswilding]

I removed parts of my zsh config until I found what was causing the performance issue I was experiencing. Removing nvm / this line from my zshenv - . "$(brew --prefix nvm)/nvm.sh" results in a significant improvement in speed when running helm-projectile-find-file. nvm.sh is a > 3000 line shell script though and I have no idea where / what to look for that might be causing the poor performance I'm seeing.

[kelsin]

Just FYI in case it helps others, I told emacs to use bash for it's shell with:
(setq shell-file-name "/bin/bash") in my config files. This sped up projectile/helm for me. For me NVM is the culprit but I want to keep using it for interactive shells.

[adandersen]

thanks @kelsin that was exactly what I needed. Like ChrisWilding i also had a similar nvm line but for fish shell. Making helm run bash instead made it snappy again

[marciol]

Just FYI for help others like me that find some problem with this issue. If you are using some kind of hook inside you bash, this will slow down projectile. In that case, inspired by @kelsin I setted in ~/.spacemacs the (setq shell-file-name "/bin/sh")

[torgeir]

+1 on @kelsin and @marciol's solution, (setq shell-file-name "/bin/sh") fixed an issue with slow helm-projectile startups for me too on zsh

[ku1ik]

On macOS projectile-indexing-method defaults to alien, and projectile-enable-caching is set to t only for native indexing method. Explicitly setting (setq projectile-enable-caching t) made it super fast again for me.

[therealpxc]

I was getting delays of several seconds (>4 seconds) when using helm-persp-switch-layout on macOS Sierra. I got a huge boost (down to < 1 second, it feels like) from explicitly enabling caching with (setq projectile-enable-caching t) in the user-config section of my .spacemacs file.

I use fish with oh-my-fish, and I made a change in the way oh-my-fish is sourced, which seems naively to have helped helm-persp-switch-layout and helm-projectile-find-file as well. I use a configuration snippet in ~/.config/fish/conf.d/omf.conf.fish to load oh-my-fish, and I simply added:

if not builtin status is-interactive
  exit
end

to the top of the file so that OMF is only loaded for interactive shells.

I'm very glad I decided to look around and found this thread, because those delays were becoming unbearable lol.

[lazyatom]

Commenting out NVM in my zsh initialisation also made a significant difference to the speed of this (and launching new terminals/shells in general).

[BigBeautifulBro]

I confirm I have this issue where helm-projectile-find-file is slow.

(setq projectile-enable-caching t) fixes the issue. Projectile was not caching on my system by default.

System Info 💻

• OS: windows-nt
• Emacs: 25.3.1
• Spacemacs: 0.200.10
• Spacemacs branch: master (rev. 4bb4cb4)
• Graphic display: t
• Distribution: spacemacs
• Editing style: emacs
• Completion: helm
• Layers:

(csv windows-scripts javascript sql autohotkey helm
     (auto-completion :variables auto-completion-enable-help-tooltip t auto-completion-enable-snippets-in-popup t auto-completion-return-key-behavior 'complete auto-completion-tab-key-behavior nil :disabled-for org erc)
     (better-defaults :variables better-defaults-move-to-beginning-of-code-first t better-defaults-move-to-end-of-code-first t)
     emacs-lisp git markdown org syntax-checking erc rust themes-megapack)

• System configuration features: XPM JPEG TIFF GIF PNG RSVG SOUND NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS

[jumarko]

I suffered from 5+ delays when doing SPC p f. After I enabled caching, things improved significantly.
I also SPC p r more often than not instead of SPC p f.

[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!

[Davidj361]

Windows user here.
Fixed my sluggish helm-projectile-find-file with (setq projectile-indexing-method 'native)