Editing remote files via SSHFS mount very slow (Sublime Text)

Question

I'm trying to nail down the best way to work on projects located on a remote server. I use Sublime Text and I've been experimenting with SSHFS on Ubuntu to mount the remote directory locally and then sync the changes across that way.

Unfortunately, when I open the remote files, Sublime becomes extremely choppy and unresponsive; it seems theres some sort of latency delay (I assume due to byte syncing), which causes Sublime to lag.

Does anyone know a way around this, or a superior way to edit a remote directory locally? Unfortunately I am not at liberty to install git on the remote server.

Answer 1

One thing to try is to open your user preferences (Preferences -> Settings-User) and set

"atomic_save": false

in it. See this question over at StackOverflow and my answer to it for an explanation of what this setting is doing, and why disabling it is often quite useful when working over a network.

Unfortunately, I'm not quite exactly sure what's going on with the issues while editing. Before saving, the contents of the file should be in memory, and disk I/O shouldn't be an issue. I'd suggest taking a look at your SSHFS settings, and seeing if something can be tweaked there. I assume you don't have any issues when editing local files?

As a suggestion (and this may not be feasible, depending on your setup) you could try moving files back and forth via the Dropbox for Linux CLI. Obviously, this is not an ideal setup for all situations, but it may help in the meantime until you can sort out the SSHFS settings.

Answer 2

Hi guys i was also facing same issue, But it has been resolve by using sublime text 2. I was trying on sublime Text 3 Beta version which Been two slow after adding remote mount folder, So i just moved on sublime text 2 and now its running fine without any delay in sync.

Answer 3

I tried @ashish-tiwari solution, and indeed the problem of slowness goes away in Sublime version 2. It seemed pretty illogical to me that a new version could handle something like that in such a different way, so I tried disabling all packages in version 3 and voila! Worked like a charm, like version 2.

Eventually, I found the culprit: VCS Gutter. I suspect any version control package would do the same, since they need to access the information about the repository on the remote FS. In any case, that worked for me, so hopefully it will help someone else as well.