Atom: Atom over sshfs Unusably Slow

[martindale]

When editing files over an sshfs connection, it takes long periods of time to perform basic actions (directory expansion, file opening). This is likely because git is running locally, but querying a remote repository many times -- can these behaviors be migrated into a non-blocking request? e.g., allow the file to open before the git repo has been read for any changes.

[jrsprice]

I can confirm this however I'm running sshfs connection over vpn and it's extremely slow and crashes the editor. Must be something with the indexing project. I also agree with martindale that the git diff checks can also slow down if it's being triggered on changes / keystroke vs on save. I remember using ST3 and there was a plugin "vcs gutter" and the code had checked svn on every keystroke making the plugin worthless and unable to type. Unnecessary round trips.

Another issue that I and another team member have experienced is the overwriting other people's changes. If I have a file open in my editor and run a git pull on my sshfs mount, the changes do not reflect in the editor however git will show there are changes. Does the editor auto save? If that's the case, this is not good since this has happened multiple times. ST3 use to have a working popup dialog that mentioned remote changes.

I'll try to get some logs on what is going on to help debug and find a solution.

OS: Mac OS X 10.9.3

[mtahmed]

I can confirm this. Also, the editor "hangs" when I try to open a directory that is sshfs-mounted. Probably because of indexing as @jrsprice said.

OS: Archlinux

[DennisBecker]

I have the same perfoamnce issues with Mac OS X 10.9.4 using sshfs for a project. Atom Editor starts really slowly compared to Textmate and plugins like "git blame" are extremely slow to show up.

[JonathanPorta]

+1

I am using Atom to edit files over an sshfs mount and saving, opening, directory browsing all take 1 - 2 seconds for each action. Sometimes saving takes 5-10 seconds.

I have also noticed that Atom doesn't seem to be an atomic file write. This is a major issue for me because I am using a watching the src directory with a compiler. As soon as Atom begins to save the file, the watcher sees that something has been modified and starts to recompile before Atom has even finished writing to the file. The end result is usually some sort of compile error.

A colleague of mine has this same issue using Sublime 2. But, in Sublime 3, the issue is fixed and writing works as expected.

[macbury]

+1 Same here. If project have a lot of files it becomes laggy as hell

[donkeybanana]

+1 would like an option to disable git integrations for working over mounted filesystems. This does not have to be automatic, if the integrations were part of a discrete package which we can toggle on demand that would be perfect for me.

[batjko]

Sounds like a possible dupe of #2313.
Accessing anything over any kind of network has always been troublesome.

[jrsprice]

I ended up using rsync via acrosync from the app store and have it automatically push local files to the server. Sublime Text has the same issue with sshfs as well.

[martindale]

I think the real answer here would be to decouple the UI rendering and the network operations (make them asynchronous).

[zuphu]

Problem still exists, I'd like to see this fixed :+1:.

[ysle]

+1

[Nikita240]

+1, slow for me too.

Makes webdev really difficult.

[macbury]

this flags for sshfs make it less laggy:
sshfs macburybury@localhost:/home/macbury/my_app ~/mounts/my_app/ -oauto_cache,reconnect,Ciphers=arcfour

[mamoit]

:+1: Unusably slow for me.
Had to go back to sublime.
Running on Debian Jessie.

[Nikita240]

@macbury Those flags did help with the performance a bit. Thanks!

[conormce]

Had the same issues as everyone here, went into packages and disabled all git related installed packages. (git-log, git-diff-popup, git-history, git-tab-status). For now it at least makes it possible to work in atom with sshfs. Also this only happens when using a VPN for me

[ypresto]

Plain git command on sshfs is very slow too.
Perhaps this is because git accesses many files in .git simultaneously.
My idea is proxying git-utils methods to remote (micro) atom instance over ssh or socket.

[mosbth]

As @Nikita240 says, the flags provided by @macbury made it a bit better. It got from unusable to workable. It still hangs on occasions though, for a few seconds. And it takes rather long time to startup.

One place it hangs is where I try to mark text, using the mouse, by double-clicking. It does not always hang, but quite often when a switch between applications and comes back to atom.

I'm running on Debian Sid. The filesystem I mounted is quite large, I guess more than 1000 files. Its a smaller part, of that filesystem, that I open i Atom, less than 100 files in three subdirectories.

More sshfs-flags to try? Any settings in Atom I might change to improve performance?

[ypresto]

Now I'm using unison instead of sshfs..!
It works perfectly for web app development on Amazon EC2!

https://discuss.atom.io/t/working-with-ssh/1737/34?u=ypresto

[willwhitney]

This is a bigger issue than it sounds. Having all of these operations block (save, git status, etc) not only causes problems for remote connections, it slows Atom down for all users. Large files have the same problems as a remote connection: saving causes jank, switching between tabs (which I think (rightly) triggers a refresh) causes stops, git operations cause jank, etc. Nothing should ever block the UI thread.

Instead, these operations should happen on a callback (and another thread, if necessary) and update the user when they complete. Saves that are taking a long time, for example, should show that in the status bar ("Saving...") without blocking, then update when they are complete.

[Proplex]

+1 this is absolutely awful. I do most of my work over sshfs, and while Atom is my favorite editor, I find Vim over SSH a lot more productive by means of less editing lag.

[HTL2001]

+1 and second what @willwhitney said. Probably going to do a script with rsync setup of some kind, since I need to poke something on the remote host when I save things anyway.

[freed00m]

+1 It affects me as well.

When I want to edit live websites it's unusable.

[bradharms]

+1 Glad to know this isn't just me. I had to start using Gedit over SSHFS because trying to open the tree view in Atom.io always takes over 10 seconds. Even just opening a subdir with a few files in it.

[AdamSimpson]

+1 , I find it barely usable as is.

[AramZS]

+1 on this.

[chaixdev]

this needs resolution!

in my personal experience the issue is especially problematic with git-managed project folders. normal SSHFS folders are slow to load, but usable after loading.

With git, not only tree operations (expanding/opening files) are incredibly slow, even simply editing files is laggy. i need to wait 2-3 seconds after each keystroke before the editor is updated and is responsive again.

In the very least, it should be possible to disable all git related features from both editor and tree view!

[ykovalev]

+1 on this

[dl00]

+1

[mykolaharmash]

+1

[Surfoo]

Same thing here with sshfs, indexing project is very slow.

[superlou]

+1

[alsemany]

+1
is there any solution for this ?
I have the same issue too, other editors are faster with sshfs however I like the atom power
sync plugin is working great however I can't download big projects to reproduce SYNC
please if tell me if there's a solution for this

regards

[sieira]

+1
Fortunatelly, I don't need to edit more than two files at a time, but it's likely to become a huge problem at some point. Meanwhile, has anyone found a workaround?

[ypresto]

I'm using unison sync tool over half the year, to edit files on AWS EC2 over ssh.
It is stable and fast!

https://github.com/atom/atom/issues/2456#issuecomment-105569181

[alsemany]

OK
yes sure this is very slow
I'm using now Remote-FTP plugin to edit using FTP and SFTP
it's very fast than using sshfs directly

[nodesocket]

I've been trying to get sshfs working performant for a few days. Essentially, I have a Linux VirtualBox VM that I want to expose a directory /var/www to OS X.

While not specially using Atom _(Sublime Text 3)_, I've noticed that Sublime Text for the most part works well, but when you switch git branches, or do any major I/O there are issues with files not deleting, or deleted files showing up and general weirdness. Trying to use SourceTree is painfully slow and basically unusable. The problem, appears to be specifically git and the amount of small file I/O git does.

I've tried various flags and options, but here is what I currently have:

sshfs -p 2222 -o ConnectTimeout=5 -o IdentityFile="$HOME"/.ssh/lightning -o defer_permissions,reconnect,volname=Lightning,noappledouble,noapplexattr,compression=yes,Ciphers=arcfour,workaround=rename [email protected]:/var/www "$HOME"/Sites/lightning/mnt

-p 2222 - We run ssh on a custom port _(2222)_
-o ConnectTimeout=5 - Timeout after 5 seconds trying to connect
-o IdentityFile="$HOME"/.ssh/lightning - Use the following ssh key
-o defer_permissions - Not really sure
reconnect,volname=Lightning - Auto-reconnect and the name that shows up in OS X
noappledouble,noapplexattr - I think noappledouble and noapplexattr are required so OS X specific files are not copied into the Linux VM.
compression=yes - Use compression. Not sure if this helps or not?
Ciphers=arcfour - Decreases the overhead of the ssh crypto, use a weak cipher suite.
workaround=rename - No idea? Found on the interweb.

Love to hear any flags people are using to improve performance, specifically git _(tons of small files being created and deleted)_). I had caching flags on, but they caused major issues when switching branches, basically the cache never invalidated and showed wrong files.

@ypresto would be very interested in a tutorial on using Unison. Basically, looking for a way to expose a directory in a Linux VM _(VirtualBox)_ to OS X.

[nolandg]

I solved this by renaming my .git file.

I was using Win SSHFS and experiencing slowness even in the editor--key strokes would take a few seconds to register. I renamed the .git folder in my project folder to .git2 and Atom is suddenly fast again, no lag in the editor, almost a local feel except for the delay in the tree. I rename the folder back again when I need to use .git. This could be wrapped in an alias too. Great work around for me because I only use git about once per day and I can automate the whole thing.

[martindale]

Nice find, @nolandg. Confirming that this works – amazing performance boost on SSHFS now. I'm curious if there's a way to simply disable access to the folder (permissions) so it doesn't have to be renamed.

[mamoit]

@nolandg doesn't that break all the git integration in atom?

[50Wliu]

Very interesting. I wonder if the recent Git work going on will help solve this. Can someone please try building Atom off of master and see if their performance is boosted while editing over SSHFS?

[50Wliu]

(Quick double-post, yay!)

If performance issues still persist, if you're feeling really adventurous you can try also building using #9213 (and maybe #10352 as well).

[nolandg]

@mamoit Yes, this does of course break all the git integration with Atom but snappy SSHFS editing is more important to me now and I'm not in an adventurous mood to build the above suggestions.

[nolandg]

Using group and owner permissions and mounting SSHFS with a different user from which you use git would probably avoid renaming yet still prevent Atom from accessing. Haven't tried though.

[steffinger]

@50Wliu I just tried to build atom from master like you suggested earlier, but still had the problem, that atom is getting unusable slow when I work on remote (sshfs) code that is in a managed by git. Its ok when the files I work on are not git managed. Is there a possibility to disable the git integration or to find out what part of atom is causing the trouble?

[50Wliu]

@steffinger You can try profiling to see where all the major slowdown is: https://atom.io/docs/v1.4.1/hacking-atom-debugging#diagnose-performance-problems-with-the-dev-tools-cpu-profiler. I don't think there's a way to turn off Git integration though.

[steffinger]

Thanks. I will try the profiling as soon as i finished my project today.

[steffinger]

I took a picture of the cpu-heaviest tasks. I don't really understand what is going on, but it doesn't look that special. Later than that I could not take any profiles, because atom "crashes" (not like consuming a lot of cpu crash, but rather like a not responsive crash). It feels more like a deadlock than a crashed process. on the operating system side of things gvfsd-sftp is showing some activity. but that is also to be expected when atom is constantly asking for files?

[hanshoglund]

+1

Serious enough to consider switching to another editor. Turning of Git intergration would be a good workaround though.

[hanshoglund]

Improved upon @nolandg 's workaround by defining:

cat >> /usr/local/bin/fit 
#!/usr/bin/env bash
mv .git12345 .git
git $@
mv .git .git12345

Now I just have to remember to type fit instead of Git...

[febLey]

There should be a way to disable the git integration completely.

[adamfranco]

@febLey, I've created a PR #11367 that adds the ability to configure certain paths (such as /mnt/ or /Volumes/) for which to totally ignore Git integration. I use this patch regularly for a Samba mount over VPN and it works like a charm. This PR could use some feedback from the Atom team, but hasn't seen any response yet.

[febLey]

Sounds promising, I'll try it out.

[febLey]

Sorry for double posting. I've done a build with those changes and it totally solves the problem.
I hope this gets merged very soon.

[lope]

+1 It was a big mistake making the UI block during file operations. Especially considering it's built on Node.js which makes async programming so natural.

Atom.io by nature is going to be interacting with stuff related to the internet frequently. Many filesystems are remote. We can't work properly if the editor freezes up for a couple of seconds regularly.

In my case I'm not even using git (no .git dir), and it lags. Ping to the server is a consistent 380ms, but the lag is often around 2-10 seconds.

Mounting with sshfs option auto_cache helps a bit.

Async file operations is a very important feature for Atom to have IMO.

[febLey]

The current 1.8.0-beta3 has definitely brought a huge improvement for me.

[marcelnem]

Still slow for me on 1.8.0. Starting atom is slow. Saving files and also tree view - expanding collapsed folder or project is slow. When I am on the local network then it is ok, when I am connectiong from home over VPN to work server then its slow. I have tried to disable all plugins that have git in name but it did not help.

When I rename .git to .git2 everything is much faster.

[jimgoo]

@nothinkelse Are there any side-effects to renaming everything from .git to .git2? Do you notice any differences other than the horrific performance with tree view, etc?

[hanshoglund]

@jimgoo I've used that setup for months (see my prev comment) and it seems to work, even using pretty advanced command sequences such as bisect and filter-branch. Having to wrap Git is still annoying of course.

[v-i-s-h]

+1
This is very annoying at time. Autocomplete freezes my atom :(

[ghost]

+1 this is still an issue for me. @hanshoglund 's workaround works for me but annoying that I no longer can use Atom's git features

[Heimdell]

+1

[Okoyl]

+1

[okaestne]

+1
Editing via ssh mounted FS (e.g. webserver) isn't fun, always short UI freezes and quite long saving-time.

@nothinkelse thanks, your workaround (renaming the .git folder) does the job for me.

Please fix :(

[sebastjaeger]

+1

[ptanov]

I think that you may try another aproach - work with local files and copy them to remote host on file change. There are multiple tools for doing this, but I'm using this:
lsyncd -nodaemon -rsyncssh folder_to_sync remote.host.com folder_on_remote_host
For more information: https://axkibe.github.io/lsyncd/

I can think for another option, too:
just use sshfs in reverse way - use local files, and mount them on a remote machine using sshfs, but this will be slow if there are large files

[anotherbugmaster]

It seems like it's an indexing related issue, because when I open local file first (and its folder is loaded as a project) and then open remote file, everything is working just fine.

I think the problem is the same as in #1847

[benzipperer]

I can confirm @anotherbugmaster 's workaround: the speed issues mostly disappear after loading a local file first, and only then opening and editing the remote file.

[dhollowa]

+1!

I regularly edit files over remote file system (150,000+ files under my project directory) and Atom's git integration is causing timeouts on the UI thread, blocking any productive work.

I've taken to renaming my top-level .git directory while using Atom, to get some work done. But Ideally, I could toggle this in Atom somehow, or have some project-level .atom-config file where I could direct Atom to not use git integration for specific projects.

This bug is definitely in the camp of "Switch back to Emacs?"... Please don't make me do that! :-)

[nkkollaw]

I'm having the same problem.

Personally, I'm mounting websites in /mnt. If I open /mnt/website.dev it freezes, but if I open the parent folder it works just fine, so I just open /mnt and it's usable (no indexing, though).

[datenstau]

+1

[jon617]

+1

Same problem here with slowness when editing a large tree of files when using a remote mounted directory. I did find a temporary solution:

I do a chmod 000 .git on the server, preventing Atom from having the ability to open the .git files. This works similarly to renaming .git as others have recommended, but I prefer chmod so I can programmatically do commits without remembering the renamed directory name or conflicting with another directory name.

Checking-in files with git is easy, simply: chmod 755 .git ; git add . ; git commit -a ; git push ; chmod 000 .git (edit the commands to suit your needs).

It would be great if Atom had the ability to IGNORE the .git directory as a configurable setting. In the meantime, this hack works.

[carolfs]

+1

[nkkollaw]

...is there any way to index the files?

A plugin/package, setting, or anything that will index every file and keep the files synchronized. I don't care if indexing takes forever, I just want it to be usable when I have to work with it.

Searching takes _forever_.

[0x6B386F]

+1. Problem is .git.

[horta]

+1

[christiantreutler-avi]

+1

[duzvik]

+1

[sanchitgera]

+1

[jodriscoll]

+1

[fulldecent]

@martindale can you please a work list with checkable items to your original issue at the top. This will help define the scope of this issue and how it can be resolved. Include measurable outcomes or visible changes you are expecting. There are already a lot of good ideas in this discussion that I need not repeat.

My company needs this to get fixed so we'd like to start a bounty on it for Atom. That will be better than waiting for Coda 3 or Transmit 6 or VS Code 2 to come out. Bounty Source is down right now so it will have to wait. But in the meantime we need a more concrete issue before we can put money on the table.

I know you opened this a long time ago. But I'd rather ask you first before starting a duplicate issue.

[TKasperczyk]

I can't believe that after 3 years there's still no way to completely disable GIT integration in Atom! @fulldecent disabling: github and git-diff packages does not prevent Atom from reading the .git folder in our projects. The only thing we want is to have an option which would cause Atom to completely ignore the .git folder in a project directory.

[fulldecent]

@Sarithis Ok, what you are describing overlaps with https://github.com/atom/atom/issues/1766

I am accessing a remote folder that does not have git and the result is also unacceptably slow.

If are you accurately describing the intended scope of this issue then perhaps I need to create a separate issue for my wider concern.

[jon617]

Over the last year, this has been my observation with working on remote code (text files) using Atom.

Scenario 1: Opening directory tree that has no .git folder, or .git folder has been renamed or chmod 000 .git to disallow anything from reading it. Latency to the server is about 30ms.

• Initial open: a little slow maybe a minute to open the directory tree. Depends on the latency between my laptop and the server where the files are stored. This only happens once (on the initial open) so not a big deal.
• Saving: Quite fast to save each file. Normally under 1 second, sometimes 2 seconds, rarely above 5 seconds.
• Closing a tab: Also fast, almost instantaneous.

FYI. After the "initial" open of the directory tree in Atom, I can put the .git folder back (or chmod 750 .git to re-allow permissions), and it does NOT trigger slowness in Atom. So, I get my git features back, and Atom runs faster.

Scenario 2: Opening directory tree that has a .git folder at the time Atom opens the directory tree. Latency to the server 30ms.

• Initial open: takes 2-4 times longer than Scenario 1. My test code with 50 text files in 20 dirs takes at least a 2 minutes to open (over 4 minutes when latency spikes to 100ms).
• Saving: takes at least 5 seconds, sometimes as much as 45 seconds JUST TO SAVE CHANGES to a single file. Makes coding incredibly slow.
• Closing a tab: also takes far longer than expected. About 2-6 seconds to close each tab.

So, my observation is, the "initial" load when Atom opens a directory tree scans the .git folder and does some processing. If it fails to open the .git folder for any reason (no permission, not exist, etc.) it never seems to try again for the duration that Atom instance stays open, creating a more pleasant experience when editing files on remotely-mounted systems.

Hope this info helps. If there was a feature to "turn off" processing the .git folder on the initial load of a directory tree open, I think Atom would work much better.

[Aporie]

+1

[martindale]

@fulldecent I'm pretty sure that a transition to an asynchronous call for whatever is the equivalent of fs.stat here would be the answer to both problems. I'm happy to take a look at the code at this point (it's been 3 years since I opened this issue), but no one has showed up to give guidance yet.

Where is @GitHub or @Atom on this? I am so surprised that this is a synchronous call, it seems to be a huge burden for tons of folks.

[nkkollaw]

Guys, is there any fix of any kind for this?

I moved to VS Code because of this, but I still like Atom's UI better.

[avball]

I just gave up and switched back to coding locally and using git to update
the dev environment to test.

On Jan 7, 2018 2:46 PM, "Niccolò Brogi" [e-mail] wrote:

Guys, is there any fix of any kind for this?

I moved to VS Code because of this, but I still like Atom's UI better.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/atom/atom/issues/2456#issuecomment-355851294, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AVENScnrXlgOkYR-WWM_Jx9xVEcQLiPBks5tIS0cgaJpZM4B_0bW
.

[Aporie]

You can try with this package. It's not as cool as just opening a folder from a directory mounted with sshsf, but for me it has done the trick.
Hope this helps

[nkkollaw]

@Aporie, that looks good as a workaround. So, you basically connect via that plugin instead of sshfs right?

(still wonder why Atom can't make it work, though)

[frederickjh]

I think that the problem has been identified as being the time it takes to read all the files in the .git folder. I guess the question is should atom ignore the .git folder by default? Or should someone write a plugin that would ignore the .git folder to eliminate this issue?

I have seen a big slow down with git itself over ssh when I have a large number of files that have change in a repo. I recently did an update to a CMS on a website and with a major reorganization of files and experienced this.

[nkkollaw]

@frederickjh : that doesn't seem to be the case.

I mounted a subfolder with only a handful of files and still experienced painfully degraded performance.

[frederickjh]

@nkkollaw I think you are correct. There is a lot of noise in this thread about the .git folder. Looking over the thread again I see that indexing of files as pointed out by @anotherbugmaster in this comment could be the issue.

Can you try anotherbugmaster's solution? Open a local folder as the project folder then open the remote file and see if the speed is better.
If this is the case then it could be the periodic rescanning of the remote folder to index the files that is slowing it down. Of course if your project folder is a remote folder using git then the problem increases because of the number of new files this adds to be indexed.

[nkkollaw]

Thanks, @frederickjh.

So, basically I have to trick Atom into indexing a local folder and just edit remote files one by one. That makes sense!

I wonder why indexing takes so long for remote folders even if it's an handful of files, though... :-/

[frederickjh]

@nkkollaw , I think that finding the answer to your question will reveal what is at the heart of this issue that needs to be fixed.

My guess is that once a folder is open as the project folder Atom keeps scanning a regular intervals for changes in the files in the folder. Maybe it is trying to bite of too much at once and trying to scan a bunch files at once which slows the ssh connection.

[nkkollaw]

My guess is that once a folder is open as the project folder...

I wish I knew how Electron worked and I could just look at the source code and see what Atom actually does.

Unfortunately, I wouldn't know where to start.

[50Wliu]

The issue is the synchronous Git calls that we use. There are plans to convert those calls to async but there's no timeline on that.

[nkkollaw]

There are plans to convert those calls to async but there's no timeline on that.

@50Wliu of course not, if not it would be true that you actually care about performance (see http://blog.atom.io/2018/01/10/the-state-of-atoms-performance.html) ;-)

[nkkollaw]

@frederickjh : I think it's definite that the problem lies with directories with too many files in subdirectories of the root project folder.

It also feels like Atom looks into parent directories for a .git folder, since if one opens a subdirectory to avoid scanning the .git folder there is little difference.

[vlsd]

I see two separate problems here, and one is definitely worse than the other:

a. Atom looks around for a .git folder and parses it and it's hard to make it stop doing that
b. Disk access blocks, and slow disk access (in this case because it's over the network) makes the UI unusable; this latter problem is, in my opinion, a huge bug for pretty much any application written after 1990

[nkkollaw]

@vlsd you're right. It's weird that Atom looks in parent directories, too.

[AHolliday]

+1 to this issue. I recently switched to Atom from Emacs, and was really enjoying it for writing code locally or in remote Hg repos over sshfs, but then I tried working in a remote Git repo over sshfs and it became unusably slow. I've had to go back to using Emacs for working on that project.

[adsbxchange]

Just tried to use Atom over sshfs. Atrocious just typing. is it seriously saving every letter?! Then googled ... Confirming this needs to go to top of priority list. Ubuntu 16.04.3

[JohnTheodore]

woah, my workflow using sshfs doesn't work well with atom. :(

[nkkollaw]

We know. Use VS Code.

[maofree]

Hi
I get a similar problem with sftp on my local lan where I edit files from my pc to the local server.
In my case when I save "ctrl + s" the content of small file size is cleaned, so I get a void file in the server, instead for big file like 100kb it is not saved but the content is not cleaned.
In both cases I need to save more time to save the last change.

with other editors it is ok

I use archlinux with gnome 3.28.1 on my pc and debian 9.4 on the server
with the last upgrade of atom the problem is bigger because now I cannot see if the file is saved in the correct mode, before the blu point remains blue and only after more save it saved correctly

Atom : 1.27.1
Electron: 1.8.4
Chrome : 59.0.3071.115
Node : 8.2.1

I connect to the server with sftp from Nautilus

Is it necessary to create a new bug topic for this problem?

thanks
bye

[martindale]

This has recently gotten worse; even after binding my sshfs mount one level up from the .git directory (thus disabling the git checks, presumably), I now experience regular 30-90 second freezes of the application before being presented with an "Editor not responding" screen. After clicking "Keep Waiting", the cycle repeats a few times, then finally my action completes.

Can we get _any_ commentary from one of the core devs on where a contributor might look to fix this?

[frederickjh]

This issue is exactly the reason I have moved on and use another editor, well actually an IDE. It may not have all the bells and whistles that Atom does or that can be added to Atom, but it doesn't slow down my work either. It would be nice to have both, but we don't always get want we want in life. :wink: :sunglasses: :innocent:

[lee-dohm]

Thanks for all the feedback.

Unfortunately, on review with the team. This isn't something that we have the resources or expertise to test and debug. None of the development team uses sshfs for our work, let alone over a slower network connection which seems to be part of the root cause of the problems experienced here. Because of this, this isn't something we're going to be able to work on. Rather than continue to leave this open, creating an expectation by some that we will work to fix it, we're going to close this issue. If someone with the resources or expertise wants to attack this, we would be willing to possibly consider an RFC with a proposal on how they intended to fix it before submitting a very well-written pull request.

Thanks for your patience and understanding.

[adsbxchange]

It does it on a 10gbit lan. What are you saving that is every keystroke?

[JordanMajd]

@lee-dohm Thank you taking the time to review this issue with your team.

I understand this is an open source project, your team has a limited amount of resources to allocate and this is not high enough of a priority. That is 100% fair and reasonable.

Next time you close an issue, you might be better off stating just that. The addition of disingenuous statements just serves to patronize your user base. Some examples from your statement to illustrate my point:

None of the development team uses sshfs for our work

But your users do; what are you trying to communicate with that statement? I read it with the implication that user issues don't matter.

a slower network connection which seems to be part of the root cause of the problems experienced here

Nobody in this thread has mentioned their connection bandwidth or latency. This occurs on a 1gb/s LAN. While I'm sure network conditions exacerbate the issue, the issue still exists in the best of conditions.

[lee-dohm]

Thanks for the feedback @JordanMajd. I'll keep it in mind for next time. I certainly wasn't trying to communicate or even imply that the problems that people run into don't matter.

[AHolliday]

Further to the comment @JordanMajd, I felt the below statement seemed a little weaselly:

this isn't something we're going to be able to work on.

You can choose to work on whatever problems you wish. If you choose not to try to fix this because it's not high enough of a priority, that's fine - but that's still a choice, nothing to do with ability. Just say "we've decided not to work on this."

[frederickjh]

Yes, making excuses doesn't help but hey when an issue has been open for over 4 years with little movement in the correct direction, like this one, I gave up hope a long time ago that this would ever be fixed. Git integration does not help. I have seen the terminal slow down when using git with a very large number of file that have changed, but this goes deeper than that.

[martindale]

Thanks for all the feedback.

Unfortunately, on review with the team. This isn't something that we have the resources or expertise to test and debug. None of the development team uses sshfs for our work, let alone over a slower network connection which seems to be part of the root cause of the problems experienced here. Because of this, this isn't something we're going to be able to work on. Rather than continue to leave this open, creating an expectation by some that we will work to fix it, we're going to close this issue. If someone with the resources or expertise wants to attack this, we would be willing to possibly consider an RFC with a proposal on how they intended to fix it before submitting a very well-written pull request.

Thanks for your patience and understanding.

Patience yes, understanding no — I thought I provided very clear guidance as to how this could be resolved in the original report? It's _extremely_ likely that this would be resolved by converting blocking I/O requests into asynchronous requests. I'm heavily disappointed (and disheartened about Atom's future) by this response, _especially_ as the issue has been closed.

It's extremely simple to duplicate this issue; set up a remote server, configure SSH, clone a repository (say, the Atom repository), then use the following command to experience this for yourself:

mkdir ~/example && sshfs -o reconnect USERNAME@server:/home/USERNAME ~/example && atom ~/example

Try to navigate around the directory tree, make some modifications, save your file. The problem should be clear, and if you attach a debugger, you'll certainly see where the slowdown comes from.

How else can I help?

[frederickjh]

@martindale I think you maybe failing to understand the concepts surrounding open source projects. Or put another way the pros and cons of open source.

I preface my comments with this, that nothing I am writing is directed at the maintainers of the Atom project. In fact I say thanks you to them for the time and effort that they put into the Atom project.

Just because you report a bug or even give very good directions on how to replicate or fix an issue, the maintainers of an open source project have no obligation to do anything with that information. I do mean anything, as in not even responding to your request.

If maintainers of projects let every user dictate what should be included in their project we would have a lot of open source messes. Projects that try to please everyone but in the end are so unfocused that no one fully understands them nor can figure out how to fully use them.

At this point the maintainers have stated their position that due to their lack of resource or expertise to debug this issue, they are closing it as won't fix. I guess the bigger question is if the Atom team is still open to a pull request that would fix this? Some how I think that if someone else is willing to take this task on and contribute to Atom by writing / fixing code to make a pull request, it would not be out right rejected by the maintainers.

Yes, submitting issues and commenting to help find or create solutions is also an important way to contribute to open source. Please keep doing this even if things you submit never make it into the project.

Then next time you feel that you are entitled to have your favorite open source issue fixed, first remember you are not. Then thank the maintainers that have put in countless hours of time to create and maintain that project.

One of the pros of open source is that there are other projects that you can move to if the one your are currently using does not meet your needs. I used Atom for a time and as I have previously stated in this thread I no longer do mainly because of this issue (there are other issues too, like being a bit of a resource hog). While I have some coding skill I have no previous knowledge of the Atom code and would most likely need to spend many hours to get up to speed in order to work on this issue.

I chose another route. Which was to switch to using the Geany IDE. Its GIT integration works over SSH connections and does the things I need. What more could I ask for.

I am not trying to step on any toes, just trying get people thinking sensibly. I am not trying to get people to stop using Atom either. If it works for you and helps you in your work and does not hinder you or slow you down, use it and help the maintainers however you can.

[Arcanemagus]

I guess the bigger question is if the Atom team is still open to a pull request that would fix this? Some how I think that if someone else is willing to take this task on and contribute to Atom by writing / fixing code to make a pull request, it would not be out right rejected by the maintainers.

As was stated in the closing message:

If someone with the resources or expertise wants to attack this, we would be willing to possibly consider an RFC with a proposal on how they intended to fix it before submitting a very well-written pull request.

[martindale]

I guess the bigger question is if the Atom team is still open to a pull request that would fix this? Some how I think that if someone else is willing to take this task on and contribute to Atom by writing / fixing code to make a pull request, it would not be out right rejected by the maintainers.

As was stated in the closing message:

If someone with the resources or expertise wants to attack this, we would be willing to possibly consider an RFC with a proposal on how they intended to fix it before submitting a very well-written pull request.

I literally described how to fix this in the original report. It's probably an easy fix for someone more familiar with the code/platform than I am. Pretty disappointing, even knowing there's no obligation for the developers to care about their downstream users. I'd love to have fixed this myself, quite frankly, but since the developers didn't even give me any guidance as to where to look, I just haven't been able to invest the time into learning a whole new project.

In the meantime, I'm still using Atom, and _tolerating_ the 2-3 minute pauses as the UI freezes up on a synchronous disk write. Seems silly that Atom is blocking the UI with I/O operations, and doubly silly that git functionality can't be disabled.

Now if only I could figure out how to prevent the "Not responding window" from stealing focus while I'm typing, almost _always_ resulting in an insta-close of my workspace when it happens... :angry:

[okare1]

For me, the main issue is 2-5s lags as I type when there is latency with the file server. Seems like the editor blocks on fstatSync calls every time the buffer content changes to determine if the file is different from the disk version. Why anyone thought it was a good idea to use sync calls for something so performance-sensitive is beyond me. Maybe they dismissed the possibility of network fs involvement completely? Since local disk i/o is fast enough to perform on the order of milliseconds.

I don't think the dev team needs to try to replicate the issue at all. I think the first priority is to change all the sync fs calls to async and then we can go from there. I don't think this should be done/proposed by anyone not extremely familiar with the project, given how many things this could potentially break if not done properly.

Right now, this issue seems to include a bunch of different network i/o-related issues jumbled together due to common manifestation.

[lee-dohm]

@G2G2G2G and @adsbxchange your comments were deleted as a violation of the Atom Code of Conduct as they were insulting or derogatory. You may consider this an official warning.