Projectile causes emacs lag on remote filesystems

[barrkel]

I'm running projectile-20150216.843 from melpa.

Cursor movement and scrolling in particular is incredibly slow when editing files on locally mounted high latency remote filesystems.

Using system monitoring tools, I can see that the file system is accessed on every keystroke. If the filesystem doesn't respond quickly, emacs lags. Remote filesystems don't necessarily respond quickly; this makes emacs lag.

When concurrent activity uses remote filesystem bandwidth, emacs effectively freezes.

I previously reported this as #448. I've just upgraded; it's still happening.

I can verify that changing the mode line variable to a constant string removes the lag:

(setq projectile-mode-line "foo")

With this set, everything becomes smooth again.

Projectile is pretty much unusable for me in its current state.

I simply don't see why the projectile mode line needs to be updated for every cursor move. The project a file belongs to almost never changes after being opened.

[bbatsov]

Projectile is pretty much unusable for me in its current state.

I simply don't see why the projectile mode line needs to be updated for every cursor move. The project a file belongs to almost never changes after being opened.

Originally the modeline was updated just on file opening, but I opted to to remove some custom code in favour of the standard Emacs tooling, which sadly updates the modeline on each keystroke. Changing this back would be trivial or we can simply disable it for remote files. I understand your frustration but for me this is a tiny problem with known workaround in one of the dozen of projects I maintain (meaning I can't deal with every problem in a prompt manner).

[Silex]

I was very close to make a PR reverting the :lighter change, but it feels "wrong". The more correct thing to do is to refactor the cache system once and for all so it caches the project root correctly instead of the hacks we have in place at the moment.

Unfortunately, it seems that some of the problems brought by :lighter are simply not solvable, see #523.

So maybe it's better to revert back to the "file opening" method?

[vspinu]

The problem seems to come from the use of file-truename. file-truename is very slow because it basically checks for simlinks at each level of the directory. When I remove both instances all the remote problems seem to vanish. I am moving inline for further discussion.

[behrica]

I am not sure, if this bug report is the correct place or it should be a new bug.

I noticed still with latest projectile a slide lag every second or so, while scrolling down/up in a directory which is on a mounted webdrive under linux.

I debugged it on davfs2 level and noticed that every time I scroll a line, emacs checks the existence of three files/dirs:
CVS
.svn
Makefile

This is basically the content of variable projectile-project-root-files-top-down-recurring.

It is not super annoying, but disturbes, specially as it does not only occur while I scroll the file list, but as well in other buffers (like help) while the working directory of the buffer is a remote webdav directory...
So I can reproduce it by opening a remote webdav folder with dired, and while I am there pressing 'C-h m' to get help for the mode. Switching to the help buffer 'C-x o' shows me now the dired and the help buffer side by side with cursor in help. Scrolling the help buffer in this situation checks the filestsyem after each scroll of a line in the help buffer.

I solved my problem by enabling the cache for local file existence:
(setq projectile-file-exists-local-cache-expire (* 5 60)))

[vspinu]

I have also noticed considerable slowdown of projectile on remotes since a month or two ago. I have deactivated projectile altogether because I haven't had time to debug it.

In my case I was not sure if it was a regression on projectile or with tramp as I have updated emacs as well.

[floli]

I'm having this behavior too, Emacs 24.5.1 / projectile-20151130.1039. It can be solved with the beforementioned (setq projectile-mode-line "foo") but otherwise it makes my Emacs unusable on remote (sshfs) and tramp filesystems.

[barrkel]

I'm working around this performance problem using two techniques. (1) I don't enable projectile unless I'm editing a file that belongs to a .git repo, and (2) I use advice to memoize the modeline function (specifically the slow bit: projectile-project-name).

Here's the snippet from my .emacs:

(add-hook 'find-file-hook
          (lambda ()
            (if (locate-dominating-file default-directory ".git")
                (projectile-mode))))
(eval-after-load "projectile"
  '(progn
     (defvar-local bk/projectile-project-name-cache nil
       "Cached value of projectile-project-name")

     (defadvice projectile-project-name (around bk/projectile-project-name activate)
       (if (not bk/projectile-project-name-cache)
           (setq bk/projectile-project-name-cache ad-do-it))
       (setq ad-return-value bk/projectile-project-name-cache))))

This snippet assumes that you only want to use projectile in .git repos. Adjust to taste.

I'm using older defadvice because 24.3 on Ubuntu 14.04.

Caches are generally a terrible way to solve performance problems because they turn invalidation into a global problem; bugs from missing invalidation are often worse than bad performance, and adding global state mutation to effect invalidation greatly harms modularity and clear code logic. In this case though the information being cached is mostly cosmetic and should almost never change.

[maximvl]

Hi guys, this issue is closed, but I'm still suffering from lags and have to turn projectile on/off all the time. Happens on emacs 24.5 and projectile 20160526.832.

[mtnmts]

This bug definitely still exists, the fix suggested by @behrica does work, he suggested setting the following variable:

(setq projectile-file-exists-local-cache-expire (* 5 60)))

I reproduced the error on Emacs 25.1.1 Compiled 2016-10-13 on Fedora 25, It froze when working over SSHFS (just like people previously described).