Accessing files on network drives is slow

[izuzak]

Reported via Halp:

• support/6290a694aa0611e38d8242e11b72b07d

Accessing files on network drives appears to be much slower than Sublime for the same mount & file. Additionally, the "Keep Waiting" decision box pops up almost every time.

I don't have a network drive, so I didn't verify this. 🚗

Edit: more reports:

• support/4e6fe392af5a11e38b62f01b0c57459b

[kevinsawicki]

After investigating this it looks like node's fs.realpathSync is pretty slow for network drives and most of the time is spent internally calling lstatSync.

Will re-profile after upgrading to atom-shell 0.14

[kevinsawicki]

After investigating this it looks like node's fs.realpathSync is pretty slow for network drives and most of the time is spent internally calling lstatSync.

Will re-profile after upgrading to atom-shell 0.14

[sincontri]

Please this is a blocking issue for those needing to edit files over sftp.
I'm on Ubuntu 14.04, atom 116.
Many thanks!

[sincontri]

Please this is a blocking issue for those needing to edit files over sftp.
I'm on Ubuntu 14.04, atom 116.
Many thanks!

[iRet]

Slow on afp shared folder. Intermittent becomes almost irresponsible.
Connection is about 50mb/s, another editors works well on same share.

[iRet]

Slow on afp shared folder. Intermittent becomes almost irresponsible.
Connection is about 50mb/s, another editors works well on same share.

[philipgiuliani]

Im also a OSX network user, so my working directory is on a server. Atom is running compared to at-home (where im working locally) really slow here, but i can work with it.

The most annoying thing is the toggle speed of the tree-view. When i toggle a folder it needs very long to show the files in there.

[philipgiuliani]

Im also a OSX network user, so my working directory is on a server. Atom is running compared to at-home (where im working locally) really slow here, but i can work with it.

The most annoying thing is the toggle speed of the tree-view. When i toggle a folder it needs very long to show the files in there.

[iRet]

@philipgiuliani sometimes it works for me as slow as usual, but another time words appears after a few seconds after typing, it's not usable. I thought something is happened with my connection but sublime fast as hell on same share, tried to restart atom nothing helped.

[iRet]

@philipgiuliani sometimes it works for me as slow as usual, but another time words appears after a few seconds after typing, it's not usable. I thought something is happened with my connection but sublime fast as hell on same share, tried to restart atom nothing helped.

[lee-dohm]

I use sshfs for network access on OS X and it is a little bit slower, but only noticeable on really large file trees. Maybe using a different protocol would help?

[lee-dohm]

I use sshfs for network access on OS X and it is a little bit slower, but only noticeable on really large file trees. Maybe using a different protocol would help?

[sincontri]

I noticed it is working much faster now, on sshfs network mount, both linux and mac os.
Thanks

[sincontri]

I noticed it is working much faster now, on sshfs network mount, both linux and mac os.
Thanks

[Nikita240]

+1, slow for me too.

Makes webdev really difficult.

[Nikita240]

+1, slow for me too.

Makes webdev really difficult.

[GM-Alex]

Same for me with 0.177.0

[GM-Alex]

Same for me with 0.177.0

[toddbu]

Same for me on the last few releases including 0.187.0. I'm running SMB shares on a CentOS server running under VirtualBox on the same Mac that I'm running Atom on. It's really random but happens once or twice a day. When I close the process Atom stays running and I have to force quit the app.

[toddbu]

Same for me on the last few releases including 0.187.0. I'm running SMB shares on a CentOS server running under VirtualBox on the same Mac that I'm running Atom on. It's really random but happens once or twice a day. When I close the process Atom stays running and I have to force quit the app.

[pheuter]

Same on Atom 0.188.0, having a hard time opening an smb drive from virtualbox on OS X.

[pheuter]

Same on Atom 0.188.0, having a hard time opening an smb drive from virtualbox on OS X.

[JohnRoach]

I will like to inform you that this(loading mounted drive folders or files) also is slow in Windows 7.

[JohnRoach]

I will like to inform you that this(loading mounted drive folders or files) also is slow in Windows 7.

[benjamindean]

In addition, fs.realpathSync is, actually, slow for almost everything. This happens only when opening file using context menu (Open With) on remote server (using nautilus in my case). Don't know the reasons, but that's was the issue for a long time. This is, probably, avoidable by not using something other than readFileSync and writeFileSync when path are not in the System context. Anyway, nothing as fast as a native implementation.
Nothing bad happens when opening the same file from Atom, thou.

[benjamindean]

In addition, fs.realpathSync is, actually, slow for almost everything. This happens only when opening file using context menu (Open With) on remote server (using nautilus in my case). Don't know the reasons, but that's was the issue for a long time. This is, probably, avoidable by not using something other than readFileSync and writeFileSync when path are not in the System context. Anyway, nothing as fast as a native implementation.
Nothing bad happens when opening the same file from Atom, thou.

[medfreeman]

Same on Ubuntu 14.04, accessing a SFTP server through Nautilus.

[medfreeman]

Same on Ubuntu 14.04, accessing a SFTP server through Nautilus.

[eikeco]

I am accessing files via a Parallels Virtual Machine and having the same problem. I'm on a Mac.
Atom Version 1.0.0.

Even when a file is open it takes a moment to catch up with what you type.

[eikeco]

I am accessing files via a Parallels Virtual Machine and having the same problem. I'm on a Mac.
Atom Version 1.0.0.

Even when a file is open it takes a moment to catch up with what you type.

[leonardfactory]

Same here with 1.0.0. Parallels VM with Windows 8, I'm working on a Mac.

[leonardfactory]

Same here with 1.0.0. Parallels VM with Windows 8, I'm working on a Mac.

[jryanad]

Having an issue as well. Atom 1.0.7 with running Virtual Box and connecting via smb on Mac 10.10.5. Just continually loads most times and have to restart the process to get it to "kick in".

Edit
However, I just disabled the Recent Projects package and now it seems to load up fine. Will continue testing and report back.

[jryanad]

Having an issue as well. Atom 1.0.7 with running Virtual Box and connecting via smb on Mac 10.10.5. Just continually loads most times and have to restart the process to get it to "kick in".

Edit
However, I just disabled the Recent Projects package and now it seems to load up fine. Will continue testing and report back.

[incognick]

Same issue Atom 1.1.0 Windows 7. Accessing a mapped network drive. I dropped a folder into Atom and the GUI locked up. Clicking on any folder locks up the GUI unless I wait 30+ seconds. I can browse the folders using windows explorer with only a slight delay (1-2 seconds).

[incognick]

Same issue Atom 1.1.0 Windows 7. Accessing a mapped network drive. I dropped a folder into Atom and the GUI locked up. Clicking on any folder locks up the GUI unless I wait 30+ seconds. I can browse the folders using windows explorer with only a slight delay (1-2 seconds).

[VasiliDarozhkin]

I run Atom 1.2.4 on Windows 7.
Project files are on the VirtualBox Ubuntu 12.04, on the same laptop
smbd process takes about 50% of CPU (2-core virtual machine)
strace shows endless getcwd and lstat commands over the project files

[VasiliDarozhkin]

I run Atom 1.2.4 on Windows 7.
Project files are on the VirtualBox Ubuntu 12.04, on the same laptop
smbd process takes about 50% of CPU (2-core virtual machine)
strace shows endless getcwd and lstat commands over the project files

[drj-io]

Hi I was running Atom 1.3.1 on Mac. I'm mounting shares using SSHFS. It works great, but Atom becomes sluggishly slow. I've since switched back to Sublime for SSHFS projects.

Editing, saving, loading... everything. Hope this helps.

[drj-io]

Hi I was running Atom 1.3.1 on Mac. I'm mounting shares using SSHFS. It works great, but Atom becomes sluggishly slow. I've since switched back to Sublime for SSHFS projects.

Editing, saving, loading... everything. Hope this helps.

[carlosperate]

Having the same issue in 1.3.2 on Windows with mapped drives from a samba network connection, locks up constantly, it's very disruptive to the workflow, and makes it almost unusable for this kind of environments.

[carlosperate]

Having the same issue in 1.3.2 on Windows with mapped drives from a samba network connection, locks up constantly, it's very disruptive to the workflow, and makes it almost unusable for this kind of environments.

[Marox44]

Same issure here. Atom 1.5.0 on Windows. Working on folder from windows network drive makes Atom slow and laggy. (works great on local files)

I switched from Brackets recently as it also had similar issues. Unlike Brackets however, Atom loads folder pretty quickly (~20sec), but then the entire workflow (autocomplete, moving lines, switching tabs, undo-ing, etc., and even the typing itself) starts freezing and lagging.
Brackets on the other hand had serious issue opening the folder itself (up to 15min), but then the interface was working decently, having almost no performance issues (slightly at switching tabs and saving but I think it's acceptable)

I assume it has something to do with file caching.

[Marox44]

Same issure here. Atom 1.5.0 on Windows. Working on folder from windows network drive makes Atom slow and laggy. (works great on local files)

I switched from Brackets recently as it also had similar issues. Unlike Brackets however, Atom loads folder pretty quickly (~20sec), but then the entire workflow (autocomplete, moving lines, switching tabs, undo-ing, etc., and even the typing itself) starts freezing and lagging.
Brackets on the other hand had serious issue opening the folder itself (up to 15min), but then the interface was working decently, having almost no performance issues (slightly at switching tabs and saving but I think it's acceptable)

I assume it has something to do with file caching.

[ThePooN]

I recently switched from ST3 to Atom. It works great on local folders but network folders are laggy as hell. Please fix that.

[ThePooN]

I recently switched from ST3 to Atom. It works great on local folders but network folders are laggy as hell. Please fix that.

[bitswarming]

Switch back to ST3, like me))))

[bitswarming]

Switch back to ST3, like me))))

[NotChillcapped]

2 years later and this is still the case... huge bummer

[NotChillcapped]

2 years later and this is still the case... huge bummer

[ThePooN]

This issue is opened for more than a year. What's going on?

[ThePooN]

This issue is opened for more than a year. What's going on?

[carlosperate]

Maybe the original title should be changed from "Accessing files on network drives is slow" to "Accessing files on network drives makes Atom unusably slow", since the first sounds like a minor inconvenience, and the second is pretty much its current state.

[carlosperate]

Maybe the original title should be changed from "Accessing files on network drives is slow" to "Accessing files on network drives makes Atom unusably slow", since the first sounds like a minor inconvenience, and the second is pretty much its current state.

[adamfranco]

I can confirm that this problem is both present and makes Atom completely unusable on OSX Yosemite connecting to a Samba share on a gigabit university LAN. My primary mode of working is on a Mac, using Samba to mount a home directory on a Linux host in the on-campus data center. I've been heavily using Atom as my primary editor since 1.0 and this problem seems to have been getting worse recently. While Atom has always been unusable over a slower residential-via-VPN-to-university connection, usage on a local gigabit link had been workable until recent releases. I've been running the Atom beta for a while and on March 8th I first noticed the 1.6 beta locking up. At this point both 1.6.0 and the 1.7 betas are totally unusable when opening projects on a Samba share.

I'll have to download a bunch of old versions and do testing to see when the additional slow-down was added in the 1.6 beta, but that may have been more of a straw breaking this camel's back rather than the root of the issue.

[adamfranco]

I can confirm that this problem is both present and makes Atom completely unusable on OSX Yosemite connecting to a Samba share on a gigabit university LAN. My primary mode of working is on a Mac, using Samba to mount a home directory on a Linux host in the on-campus data center. I've been heavily using Atom as my primary editor since 1.0 and this problem seems to have been getting worse recently. While Atom has always been unusable over a slower residential-via-VPN-to-university connection, usage on a local gigabit link had been workable until recent releases. I've been running the Atom beta for a while and on March 8th I first noticed the 1.6 beta locking up. At this point both 1.6.0 and the 1.7 betas are totally unusable when opening projects on a Samba share.

I'll have to download a bunch of old versions and do testing to see when the additional slow-down was added in the 1.6 beta, but that may have been more of a straw breaking this camel's back rather than the root of the issue.

[wot48]

There is a random pause saving/open file. My Samba share is very fast read/write using other Windows programs. I've tried Sublime text 2/3, VS Code, Notepadd++.. none of them have this problem. It makes Atom useless over network drive, sadly I have to switch to Sublime Text for now.

Windows 10 Pro. Version 1511.
Samba 4.4

[wot48]

There is a random pause saving/open file. My Samba share is very fast read/write using other Windows programs. I've tried Sublime text 2/3, VS Code, Notepadd++.. none of them have this problem. It makes Atom useless over network drive, sadly I have to switch to Sublime Text for now.

Windows 10 Pro. Version 1511.
Samba 4.4

[adamfranco]

I've done a little bit of testing with Atom 1.7-beta0 running on OSX to a Samba share on a Linux host. My test project is tiny, with 3 project files and 1 subdirectory and a short (16-commit) git history -- a total of 73 files and directories.

After adding the project folder (another super slow process) and waiting for Atom to finish loading the project I ran strace on the Linux host and watching for access to files and directories for my samba process:

strace -f -p 22384 |& grep -P 'open|lstat'

While Atom was just sitting there was no disk activity, however after focusing to another application, just bringing Atom back to the foreground resulted in 388 lstat and open calls. While editing a file, every time typing pauses, there are usually about 27 lstat and open calls to check the state of the current buffer against the current Git HEAD.

In my testing on a larger project folder with 1,128 project files & directories, running the git status checks (over a relatively fast VPN this time) takes about 20 minutes to complete and results in 29,927 lstat and open calls.

Making the situation even worse, multiple runs of these git status checks seem to queue up if you focus to Atom and away a few times, potentially queuing up hours of I/O with just a few ALT + TAB/CMD + TAB keystrokes. For any medium-sized project, this could result in hours of waiting time.

My own hunch is that Atom's regular refresh of the Git status of the entire project tree every time the application is brought into focus is a large part of the problem. Even if you've patiently waited for the project to load, switching to another application and back starts the entire cycle over again.

One potential solution would be to split Git usage into several operational modes: "automatic", "manual", and "off" with the current behavior in "automatic" mode and the "manual" mode providing controls in the UI to trigger a status refresh of the project. The manual and off modes could potentially be enabled for only certain projects/paths, for example allowing automatic mode for local Project Folders and manual mode for anything under /mnt/ or /Volumes/.

[adamfranco]

I've done a little bit of testing with Atom 1.7-beta0 running on OSX to a Samba share on a Linux host. My test project is tiny, with 3 project files and 1 subdirectory and a short (16-commit) git history -- a total of 73 files and directories.

After adding the project folder (another super slow process) and waiting for Atom to finish loading the project I ran strace on the Linux host and watching for access to files and directories for my samba process:

strace -f -p 22384 |& grep -P 'open|lstat'

While Atom was just sitting there was no disk activity, however after focusing to another application, just bringing Atom back to the foreground resulted in 388 lstat and open calls. While editing a file, every time typing pauses, there are usually about 27 lstat and open calls to check the state of the current buffer against the current Git HEAD.

In my testing on a larger project folder with 1,128 project files & directories, running the git status checks (over a relatively fast VPN this time) takes about 20 minutes to complete and results in 29,927 lstat and open calls.

Making the situation even worse, multiple runs of these git status checks seem to queue up if you focus to Atom and away a few times, potentially queuing up hours of I/O with just a few ALT + TAB/CMD + TAB keystrokes. For any medium-sized project, this could result in hours of waiting time.

My own hunch is that Atom's regular refresh of the Git status of the entire project tree every time the application is brought into focus is a large part of the problem. Even if you've patiently waited for the project to load, switching to another application and back starts the entire cycle over again.

One potential solution would be to split Git usage into several operational modes: "automatic", "manual", and "off" with the current behavior in "automatic" mode and the "manual" mode providing controls in the UI to trigger a status refresh of the project. The manual and off modes could potentially be enabled for only certain projects/paths, for example allowing automatic mode for local Project Folders and manual mode for anything under /mnt/ or /Volumes/.

[Zireael07]

@adamfranco: Good analysis. I'd tag relevant project members if I knew who they were...

[Zireael07]

@adamfranco: Good analysis. I'd tag relevant project members if I knew who they were...

[joshaber]

Thanks for the great writeup @adamfranco! That's more or less what I found while investigating #11214.

#11277 should improve the situation somewhat, but your suggestion for an off/on/manual setting would be a great addition too.

[joshaber]

Thanks for the great writeup @adamfranco! That's more or less what I found while investigating #11214.

#11277 should improve the situation somewhat, but your suggestion for an off/on/manual setting would be a great addition too.

[MichaelThessel]

Several people in #11214 pointed out that downgrading to 1.5.4 solved the issue for them. I just did the same on my install and the situation is much improved. I still see a very high amount of stat calls as soon as I ALT + tab to Atom, but the smbd CPU utilization went down from continuous 100% to continuous < 20%. I don't see the GUI freezing anymore either. If people looking for a workaround for the time being, downgrading to 1.5.4 and disabling automatic updates might be a solution.

[MichaelThessel]

Several people in #11214 pointed out that downgrading to 1.5.4 solved the issue for them. I just did the same on my install and the situation is much improved. I still see a very high amount of stat calls as soon as I ALT + tab to Atom, but the smbd CPU utilization went down from continuous 100% to continuous < 20%. I don't see the GUI freezing anymore either. If people looking for a workaround for the time being, downgrading to 1.5.4 and disabling automatic updates might be a solution.

[adamfranco]

For reference, this gist shows all 388 lstat and open calls made when bringing Atom into focus with my small test Project Folder (3 files).

Looking at this, I notice that the project directory, .git directory, and some .git subdirectories get scanned sometimes several times during the status check for each file. It may be that the Git implementation is searching the the .git sub-directories for objects and not caching objects or the directory listings.

[adamfranco]

For reference, this gist shows all 388 lstat and open calls made when bringing Atom into focus with my small test Project Folder (3 files).

Looking at this, I notice that the project directory, .git directory, and some .git subdirectories get scanned sometimes several times during the status check for each file. It may be that the Git implementation is searching the the .git sub-directories for objects and not caching objects or the directory listings.

[adamfranco]

I've re-run my tests (from above) against a new Atom 614eb81 source-build which includes @joshaber's improvements from #11280 and #11277.

I now see 292 lstat and open calls made when bringing Atom into focus with my small test Project Folder (3 files) on a Samba share (down from 388 for Atom 1.7-beta0), a 25% drop in the number of calls. On my larger test project with 1,122 Project files I saw an even more dramatic improvement, with the number of lstat and open calls dropping from 24,731 to 12,854 -- a 48% drop in the number of calls. 🎉 Great improvements, @joshaber, thanks!

The git-status checks are still demanding quite a bit of I/O, just not quite as much as before. 😄

(This note is also relevant to #11214)

[adamfranco]

I've re-run my tests (from above) against a new Atom 614eb81 source-build which includes @joshaber's improvements from #11280 and #11277.

I now see 292 lstat and open calls made when bringing Atom into focus with my small test Project Folder (3 files) on a Samba share (down from 388 for Atom 1.7-beta0), a 25% drop in the number of calls. On my larger test project with 1,122 Project files I saw an even more dramatic improvement, with the number of lstat and open calls dropping from 24,731 to 12,854 -- a 48% drop in the number of calls. 🎉 Great improvements, @joshaber, thanks!

The git-status checks are still demanding quite a bit of I/O, just not quite as much as before. 😄

(This note is also relevant to #11214)

[joshaber]

That's great news @adamfranco! Thanks for re-running the numbers.

[joshaber]

That's great news @adamfranco! Thanks for re-running the numbers.

[adamfranco]

I've been poking a bit at tree-view to see what effect disabling it's git-status checks can eliminate the intense I/O by commenting out a few lines in the tree-view module:

diff --git a/lib/directory.coffee b/lib/directory.coffee
index 279b64b..251141c 100644
--- a/lib/directory.coffee
+++ b/lib/directory.coffee
@@ -30,7 +30,7 @@ class Directory
     @status = null
     @entries = {}

-    @submodule = repoForPath(@path)?.isSubmodule(@path)
+    # @submodule = repoForPath(@path)?.isSubmodule(@path)

     @subscribeToRepo()
     @updateStatus()
diff --git a/lib/helpers.coffee b/lib/helpers.coffee
index 3135dfd..b059f9b 100644
--- a/lib/helpers.coffee
+++ b/lib/helpers.coffee
@@ -2,6 +2,7 @@ path = require "path"

 module.exports =
   repoForPath: (goalPath) ->
+    return null
     for projectPath, i in atom.project.getPaths()
       if goalPath is projectPath or goalPath.indexOf(projectPath + path.sep) is 0
         return atom.project.getRepositories()[i]

What I've found is that this hack does seem to eliminate almost all of the git-related I/O. That said, it seems that something else in Atom is still doing a full-depth scan of every file & directory in Project Folders on Atom-focus -- even with the tree-view module and almost all core and community modules are completely disabled. I've been able to trigger this full Project Folder scan-on-focus effect even when quitting and re-starting Atom with tree-view disabled.

Ideally, when a Project Folder is added to the editor and git-status checks are disabled, only the visible (expanded) directories & open files would be stat-ed on focus, not the full-depth contents of Project Folder. Maybe if we can figure out what else is scanning the Project Folder then a two-pronged approach to get Atom's I/O down to usable levels on networked file-systems:

• stop tree-view git-status checks
• stop the other Project Folder scan

[adamfranco]

I've been poking a bit at tree-view to see what effect disabling it's git-status checks can eliminate the intense I/O by commenting out a few lines in the tree-view module:

diff --git a/lib/directory.coffee b/lib/directory.coffee
index 279b64b..251141c 100644
--- a/lib/directory.coffee
+++ b/lib/directory.coffee
@@ -30,7 +30,7 @@ class Directory
     @status = null
     @entries = {}

-    @submodule = repoForPath(@path)?.isSubmodule(@path)
+    # @submodule = repoForPath(@path)?.isSubmodule(@path)

     @subscribeToRepo()
     @updateStatus()
diff --git a/lib/helpers.coffee b/lib/helpers.coffee
index 3135dfd..b059f9b 100644
--- a/lib/helpers.coffee
+++ b/lib/helpers.coffee
@@ -2,6 +2,7 @@ path = require "path"

 module.exports =
   repoForPath: (goalPath) ->
+    return null
     for projectPath, i in atom.project.getPaths()
       if goalPath is projectPath or goalPath.indexOf(projectPath + path.sep) is 0
         return atom.project.getRepositories()[i]

What I've found is that this hack does seem to eliminate almost all of the git-related I/O. That said, it seems that something else in Atom is still doing a full-depth scan of every file & directory in Project Folders on Atom-focus -- even with the tree-view module and almost all core and community modules are completely disabled. I've been able to trigger this full Project Folder scan-on-focus effect even when quitting and re-starting Atom with tree-view disabled.

Ideally, when a Project Folder is added to the editor and git-status checks are disabled, only the visible (expanded) directories & open files would be stat-ed on focus, not the full-depth contents of Project Folder. Maybe if we can figure out what else is scanning the Project Folder then a two-pronged approach to get Atom's I/O down to usable levels on networked file-systems:

• stop tree-view git-status checks
• stop the other Project Folder scan

[adamfranco]

I've done a little more debugging and found that git-repository-async.js's refreshStatus() method is being called for the full project, even without the tree-view module enabled. This is the "other Project Folder scan" that I noticed in the comment above.

It seems that project's addPath() method is registering a repositoryForDirectorySync promise that sets up the event that calls refreshStatus() every focus. This can be seen in project.coffee:

addPath: (projectPath, options) ->
  ...
  repo = null
  for provider in @repositoryProviders
    break if repo = provider.repositoryForDirectorySync?(directory)
  @repositories.push(repo ? null)
   ...

This in turn uses the GitRepositoryProvider to set up GitRepository which due to its default true value for refreshOnWindowFocus, attaches a refreshStatus() call to window.onfocus().

It looks like the GitRepositoryProvider is passing options that include project options and the config to the GitRepository, but the options are keyed as {config: {...}, project: {...} when the GitRepository is looking for the top-level refreshOnWindowFocus key, so (it at least seems) that adding a refreshOnWindowFocus value to one's .atom/config.cson wouldn't allow disabling of refreshOnWindowFocus. Editing the GitRepository to set refreshOnWindowFocus to false does successfully stop I/O on focus.

If there is a desire to keep git integration, but reduce its impact, there seem several places that are asking for full-project refreshStatus() promises when maybe they could be asking to refresh the status of a single file that was changed (on save) or just the visible files (as seen by tree-view).

To fully halt git integration it seems that putting a check in Project.addPath() to see if the current path is in an exclude-list might do the trick.

[adamfranco]

I've done a little more debugging and found that git-repository-async.js's refreshStatus() method is being called for the full project, even without the tree-view module enabled. This is the "other Project Folder scan" that I noticed in the comment above.

It seems that project's addPath() method is registering a repositoryForDirectorySync promise that sets up the event that calls refreshStatus() every focus. This can be seen in project.coffee:

addPath: (projectPath, options) ->
  ...
  repo = null
  for provider in @repositoryProviders
    break if repo = provider.repositoryForDirectorySync?(directory)
  @repositories.push(repo ? null)
   ...

This in turn uses the GitRepositoryProvider to set up GitRepository which due to its default true value for refreshOnWindowFocus, attaches a refreshStatus() call to window.onfocus().

It looks like the GitRepositoryProvider is passing options that include project options and the config to the GitRepository, but the options are keyed as {config: {...}, project: {...} when the GitRepository is looking for the top-level refreshOnWindowFocus key, so (it at least seems) that adding a refreshOnWindowFocus value to one's .atom/config.cson wouldn't allow disabling of refreshOnWindowFocus. Editing the GitRepository to set refreshOnWindowFocus to false does successfully stop I/O on focus.

If there is a desire to keep git integration, but reduce its impact, there seem several places that are asking for full-project refreshStatus() promises when maybe they could be asking to refresh the status of a single file that was changed (on save) or just the visible files (as seen by tree-view).

To fully halt git integration it seems that putting a check in Project.addPath() to see if the current path is in an exclude-list might do the trick.

[Rod-O]

If I point my fs and atom one level up, atom works fine, of course, git is not working, but I can work without problems.

[Rod-O]

If I point my fs and atom one level up, atom works fine, of course, git is not working, but I can work without problems.

[sampotts]

Cool, I'll give that a go. To be honest, I'm not bothered about the built in Git as I use tortoise on the windows box anyway.

[sampotts]

Cool, I'll give that a go. To be honest, I'm not bothered about the built in Git as I use tortoise on the windows box anyway.

[danielvoicu]

The issue - or a very similar one - is still there. I work on a network drive mapped through a SFTP connection. When I open a new project, atom shows the folder structure, but when trying to open a file, it doesn't load the content of the file, showing it as empty.

The server is mapped as a network drive on Windows 10.

[danielvoicu]

The issue - or a very similar one - is still there. I work on a network drive mapped through a SFTP connection. When I open a new project, atom shows the folder structure, but when trying to open a file, it doesn't load the content of the file, showing it as empty.

The server is mapped as a network drive on Windows 10.

[rviertel2]

I am also running into this issue. I worked on-site for about 3 months and connected to the network directly. I was able to edit network files/projects with Atom 1.9.8 and did not have any problems. Since then, I have moved out of state and now am connecting to the network over a vpn. I upgraded to Atom 1.9.9 and now editing files over the network drive is extremely slow. My machine is running Windows 10.

[rviertel2]

I am also running into this issue. I worked on-site for about 3 months and connected to the network directly. I was able to edit network files/projects with Atom 1.9.8 and did not have any problems. Since then, I have moved out of state and now am connecting to the network over a vpn. I upgraded to Atom 1.9.9 and now editing files over the network drive is extremely slow. My machine is running Windows 10.

[cy2k]

@Rod-O

If I point my fs and atom one level up, atom works fine, of course, git is not working, but I can work without problems.

To clarify what I think you meant, what I did was removed my individual project folders from the view on the left, and instead, I added a "project" that is really just a directory that contains multiple project folders in it. That seems to break the git coloring in the tree view, meaning my alt-tabs are now WAY faster, and I've just lost the coloring (which is OK for me right now, the speed is more important to me in the short term).

Great idea, thanks man.

[cy2k]

@Rod-O

If I point my fs and atom one level up, atom works fine, of course, git is not working, but I can work without problems.

To clarify what I think you meant, what I did was removed my individual project folders from the view on the left, and instead, I added a "project" that is really just a directory that contains multiple project folders in it. That seems to break the git coloring in the tree view, meaning my alt-tabs are now WAY faster, and I've just lost the coloring (which is OK for me right now, the speed is more important to me in the short term).

Great idea, thanks man.

[STLMikey]

@cy2k Im experiencing the same thing, opening the folder above my project the .git file(s) seems to drastically improve performance

[STLMikey]

@cy2k Im experiencing the same thing, opening the folder above my project the .git file(s) seems to drastically improve performance

[danielvoicu]

I found a workaround that seems to fix the lagging issue. When I had this problem, I used Netdrive2 to mount the SFTP network drive. I started using Mountain Duck, and everything seems to be ok now, I can even see the git coloring and all, without any noticeable problems in performance.

[danielvoicu]

I found a workaround that seems to fix the lagging issue. When I had this problem, I used Netdrive2 to mount the SFTP network drive. I started using Mountain Duck, and everything seems to be ok now, I can even see the git coloring and all, without any noticeable problems in performance.

[elchinillo]

Same thing for me. I have a network location on windows 8, which is a folder shared using Samba on an Ubuntu VM. I have to wait several seconds to open an small file.

[elchinillo]

Same thing for me. I have a network location on windows 8, which is a folder shared using Samba on an Ubuntu VM. I have to wait several seconds to open an small file.

[Celadora]

Disabling the package "Git Diff" seemed to help, but I haven't confirmed that yet, it might be a fluke.

[Celadora]

Disabling the package "Git Diff" seemed to help, but I haven't confirmed that yet, it might be a fluke.

[julenpardo]

Same here with Linux Mint 18 and:

Atom    : 1.14.2
Electron: 1.3.13
Chrome  : 52.0.2743.82
Node    : 6.5.0

[julenpardo]

Same here with Linux Mint 18 and:

Atom    : 1.14.2
Electron: 1.3.13
Chrome  : 52.0.2743.82
Node    : 6.5.0

[arashdb]

I am observing this issue (both on windows(64bit) and on Ubuntu). If I have a few files open from my network drive and close Atom, next time I open up Atom, all those tabs (expectedly) open up, but it freezes and will not respond to any commands unless I open up a new window and close the frozen window. If all the open files are local (and not on a network drive) this issue will not happen.
I did turn off the "Git Diff" and saw no change in the behavior. Is there any chance that it might be an indexing issue?

[arashdb]

I am observing this issue (both on windows(64bit) and on Ubuntu). If I have a few files open from my network drive and close Atom, next time I open up Atom, all those tabs (expectedly) open up, but it freezes and will not respond to any commands unless I open up a new window and close the frozen window. If all the open files are local (and not on a network drive) this issue will not happen.
I did turn off the "Git Diff" and saw no change in the behavior. Is there any chance that it might be an indexing issue?

[nkkollaw]

The issue seems to be caused by the .git folder, or more precisely by the tree view trying to color files and folders according to their status.

If you open the directory above the .git folder it loads just fine, although you don't have the coloring.

It would be nice if tree view asked you whether you want to keep parsing the directory structure when it detects performance issues (ex., after 20 seconds or so).

[nkkollaw]

The issue seems to be caused by the .git folder, or more precisely by the tree view trying to color files and folders according to their status.

If you open the directory above the .git folder it loads just fine, although you don't have the coloring.

It would be nice if tree view asked you whether you want to keep parsing the directory structure when it detects performance issues (ex., after 20 seconds or so).

[karneaud]

+1 having the same issue with latest Atom on XOS Seirra with AFP network drive.

[karneaud]

+1 having the same issue with latest Atom on XOS Seirra with AFP network drive.

[quickdraw6906]

Same on Samba. Disabling the Atom git package and removing the project folder makes it lickety-speedy. What a bummer. Workaround:

1. Don't use a mapped drive anymore. Clone the repo locally.
2. Install remote-sync package.
3. Follow instructions for package (great documentation!) to create a .remote-sync.json file in your directory to watch.
4. Add that file to .gitignore. Super fast SCP sync whenever you save a file.
5. Go into your .ssh dir. i.e., /home/sean/.ssh
6. Create a new ssh key with ssh-keygen. Copy the contents of the .pub file to the clipboard.
7. On the sync target, go into the .ssh directory of the user you put in the config file. 'data' is the user in my case:
   cd /home/data/.ssh
8. Create a file there called authorized-keys
9. Paste the contents of the key and save the file.

Didn't have to restart Atom or anything. Lightening fast!

[quickdraw6906]

Same on Samba. Disabling the Atom git package and removing the project folder makes it lickety-speedy. What a bummer. Workaround:

1. Don't use a mapped drive anymore. Clone the repo locally.
2. Install remote-sync package.
3. Follow instructions for package (great documentation!) to create a .remote-sync.json file in your directory to watch.
4. Add that file to .gitignore. Super fast SCP sync whenever you save a file.
5. Go into your .ssh dir. i.e., /home/sean/.ssh
6. Create a new ssh key with ssh-keygen. Copy the contents of the .pub file to the clipboard.
7. On the sync target, go into the .ssh directory of the user you put in the config file. 'data' is the user in my case:
   cd /home/data/.ssh
8. Create a file there called authorized-keys
9. Paste the contents of the key and save the file.

Didn't have to restart Atom or anything. Lightening fast!

[btn-ninja]

I tried Atom with Expandrive and it was unbearably slow. SublimeText3 with Expandrive was okay, but had random un-alerted failures to save, which cost me 1-2 hours per week; that solution also didn't work with the sass compiler. Does anyone recommend a solution, any editor/virtual drive combo which works reliably?

[btn-ninja]

I tried Atom with Expandrive and it was unbearably slow. SublimeText3 with Expandrive was okay, but had random un-alerted failures to save, which cost me 1-2 hours per week; that solution also didn't work with the sass compiler. Does anyone recommend a solution, any editor/virtual drive combo which works reliably?