Atom is slow regaining focus on Windows and Linux with git repo

[monkpit]

Atom has a delay of ~1 second to respond to input when re-focusing. Seems to only affect Atom when a project folder is in a git repository.

Steps to reproduce:
Open Atom
Add a directory to your project that is a git repository or a subfolder of a git repository.
Open a file or create a new document in the same Atom session.
Switch to a different application.
Click back on Atom and wait for your input to be accepted.

When you click back on Atom there is a delay of 1~1.5 seconds before your action is performed (tab switch if you clicked a tab, cursor to start blinking if you clicked in the text of a document).

I ran the profiler during the task switching and I got the following data (rename the file to .json if necessary):
TimelineRawData-20151112T091728.txt

I am able to solve the issue only by removing the git folder from my project.

I'm not versed in reading the profiling data but it looks like a call to git-repository.js is taking a lot of time up when the re-focus happens.

[monkpit]

I checked if this was only a problem when the git repo has a remote defined.

Created a directory test, ran git init and added test as my only project folder in Atom. Still have the same delay.

[benogle]

I wonder if #9469 will fix the issue for you. @thedaniel what do you think?

[thedaniel]

Back to #9213 but yeah, that's the dream. This is good to have as a test case / goal for improvement in any case.

[PaulBGD]

Does this still need reproduction? I can get it to occur every time. Windows 10.

[bellaPatricia]

insert confirmation
Any status on this?

It's really annoying and renders the editor useless.

[PaulBGD]

@bellaPatricia I've been following this, and now that #9213 is pulled it looks like the issue is fixed. We just have to wait for it to make it into a release.

[lyweiwei]

+1, my OS is windows 10

[lyweiwei]

This function takes long GitRepository.prototype.refreshStatus, it seems the editor is blocked by the underneath spawn.

I just verified the child_process.folk is blocking the thread until the child process is completed. It seems a Node bug. My Node.JS version is 4.1.1.

[50Wliu]

@lyweiwei What Atom version are you running? Can you check if 1.6.0-beta7 fixes this issue?

[lyweiwei]

@50Wliu the Atom version is 1.5.4, I just tried 1.6.0-beta7, it still repros

[wassname]

Not just windows I think. I noted this in a cpu trace on linux 64 bit, Debian betsy. Node version v5.7.1. Atom 1.4.0

self	total	function
81975.5 ms	89.42 %	spawn
81975.5 ms	89.42 %	internal/child_process.js:251
81975.5 ms	89.42 %	child_process.js:343exports.spawn
81975.5 ms	89.42 %	child_process.js:18exports.fork
81975.5 ms	89.42 %	/usr/share/atom…src/task.js:26Task
81975.5 ms	89.42 %	/usr/share/atom…src/task.js:13module.exports.Task.once
76882.4 ms	83.86 %	/usr/share/atom…ository.js:365module.exports.GitRepository.refreshStatus

Edit: Still exist on atom=1.7.1 linux 64 bit, Debian betsy, node=5.10.1.

[lyweiwei]

I don't have the bug on my Mac. OSX 10.11.3, Atom 1.5.3, Node 4.1.1

[50Wliu]

I don't have the bug on my Mac.

Hence why the bug is labeled as windows-only 😉. @joshaber @thedaniel this doesn't seem to have been fixed with async Git, unless Atom is still using the old one internally.

[scrawfor]

Here's my timeline output from this morning on 1.6.0-beta8. Looks very similar to the original that @monkpit posted.

TimelineRawData-20160315T073535.txt

[joshaber]

Yeah, even with GitRepositoryAsync, GitRepository is still Doing It's Synchronous Dance to ensure backwards compatibility with anyone using the old API. That said, we could be smarter about it: e.g., only refresh if someone has subscribed to its events.

[maleadt]

I can reproduce this on Linux (Arch, 64bit, atom 1.6.2), so definitely not Windows-only.
CPU-20160419T103753.cpuprofile.zip

Any workaround for this? Can we disable refreshOnWindowFocus? Atom is really unusable now.

[zokker13]

My workaround was to temporarily rename the git folder.
Usually until I'm done with a feature and then rename it.
Then it suddenly works.

[sorear]

Seeing the same issue on 1.7.2 (Linux)

[wassname]

Can we please have a linux tag added to this too? Two reports of this on linux so far.

[axefrog]

Also experiencing this on Windows 10. Every time the window regains focus I get an annoying pause before it becomes responsive. For me, the pause is about 1.6s which doesn't sound like a lot but when you're constantly switching back and forth during testing, it's really noticeable. I opened the developer tools and the profiler shows that GitRepository.refreshStatus() is 100% to blame for the pause.

[lautjy]

Came here from issue #8451 . In Windows 10, Atom version 1.7.3 freshly installed. Two tabs open with small text files or .md type (200 lines and 105 lines). One folder open in the left side with several .md and .py, plus other miscellaneous files in a sub-folder.
"apm list" shows that I have 89 built-in packages and 0 community packages installed.

Atom freezes randomly for few seconds on Alt+Tabbing, selecting text, or scrolling. Started noticing this today. Highly destructive for work, but doesn't happen all the time - quite rarely in fact, but in bursts. This Atom session has been up few days - been hibernated several times with Windows during this time.

Only suspicious thing I can see with a quick inspection is high memory consumption in one background process:
CPU usage seemed to be around 0% and memory at 40MB for the App-section in task manager while Atom was frozen. Just noticed that there are Atom background processes and one of them is hogging 650MB.

Restarting Atom takes that large background process' memory consumption down to 80MB. Memory consumption creeps up slowly as I write more sentences. I wrote 358 characters and Memory is now up to 108MB. After 722 characters I'm up to 150MB for that Atom background process. Again, just writing text into an .md file. That is quite some memory consumption for just few characters - unicode or not. (writing more it keeps rising, at 250MB with a bit more text)

Have not had a freeze after restart. That memory consumption is the only suspicious thing I'm seeing. Though it may or may not work as intended.

Do note:
Files and the folder are NOT in git (but they are backed up in GDrive if it matters).
So the title of this bug is incorrect for my case, and #8451 may be a separate issue.

[didibus]

This is a ridiculous issue. For a software developed by the GitHub team, making git repos render the editor almost unusable. I have to change all my .git file to stop.git to address this problem, rendering all Atom git features worthless.

[eonist]

This happens on my mac as well. Macbook 15 TouchBar 2016 2.6gh 16gb ram. It started the summer of 2017.

[derks]

Confirmed:

• macOS Sierra: 10.12.6
• Atom: 1.18.0 x86

I generally work on 6+ projects at a time in one Atom view, all Git repositories... and switch in and out of Atom/Terminal/Browser/etc constantly. Sitting at ~2-3sec refocus lag which is incredibly distracting and killing efficiency. I've disabled all un-necessary packages which didn't seem to help at all.

Any ETA on a resolution? This is unfortunately tetering on unusable.

[eonist]

@derks Strangely enough if you reboot Atom now and then the lag goes away. Maybe a clue to finding the needle in the haystack?. I've also disabled all superfluous packages and use a more or less vanilla Atom. I use: macOS: 10.12.6, Atom: 1.18.0

[kravlost]

@eonist I don't find that rebooting Atom makes any difference. If a project is a Git repo, then it's slow to regain focus every time. It makes Atom painful to use.

Windows 10
Atom 1.19.0-beta6 x64

[bradleynielsen]

Uninstall your antivirus and see if that makes a difference.

…

On Wed, Aug 2, 2017 at 8:13 AM, steronydh ***@***.***> wrote: @eonist <https://github.com/eonist> I don't find that rebooting Atom makes any difference. If a project is a Git repo, then it's slow to regain focus every time. It makes Atom painful to use. Windows 10 Atom 1.19.0-beta6 x64 — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#9544 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABoHLQp50UWgxKiktF1FcUyXZM-OMItaks5sUHX2gaJpZM4GhG_P> .

-- Brad Nielsen

[baggepinnen]

I have same issue on both fedora and ubuntu, without any antivirus software enabled.
Atom 1.18.0

[eonist]

@steronydh I have about 10-15 git projects in Atom. Some are 15k commits etc. App Reboot makes Atom responsive again only to slowly become laggy after a day of work @bradleynielsen I don't use any AntiVirus.

[eonist]

@derks @baggepinnen @steronydh @didibus I started using Atom beta and the problem went away. Could you guys try? Update: The freezing has started again. Atom beta 1.20.0 beta4

[nordboerg]

I've started to experience this only last week, it never before was an issue.

Windows 10
Atom 1.19.3

[phun-ky]

Fresh install Ubuntu 16.04, latest atom. Randomly freezes (as in I have to kill the process and restart atom) when alt+tab back to atom. Did not happen with Ubuntu 14.04.

Anyone have a workaround for this? Is this a different issue?

[Spitfire1900]

@phun-ky Check atom cpu usage, users have repored a spike per repo in their project. If this is the same issue multiple users have worked around it with #9544 (comment)

[kayakyakr]

This hit me hard starting yesterday. I think it was set off by malwarebytes, but didn't clear up once malwarebytes was removed. Applying the workaround did work.

[phoenixeliot]

I think this bug regressed some time in the last 2 months; things went from fine to incredibly laggy. Not sure the exact date. If/when I move back to an old version of atom I will see if I can pinpoint it.

I'm seeing the exact same pattern of all the CPU time being spent blocked in GitRepository.refreshStatus > .... > ChildProcess.spawn > spawn

Issue occurs even with all non-core packages disabled. Issue temporarily resolves itself when I restart Atom but gets worse over time.

Atom 1.20.0 x64
MacOS 10.11.6
Repo I'm using: http://github.com/codecombat/codecombat
Node version in the terminal I use to launch atom: 5.1.1 (but I have nvm installed)
apm -v:

apm  1.18.4
npm  3.10.10
node 6.9.5 x64
python 2.7.10
git 2.8.4

[HebaruSan]

@phoenixeliot , it gets worse with each git repo you add to the tree view, since there is more (unnecessary) work to do overall. I know that I tend to add more projects over time, so if you do as well, that could account for your experience of a trend.

If anyone has time, some assistance with the CI checks on #15510 would be appreciated and might help to get this fixed. I think it's getting ignored now because it has a red 'X' on it, but I have no idea what "Expected HTMLNode not to be defined" might mean in terms of the code. I've been using that fix since I submitted it, and it's made a night-and-day difference in terms of Atom's usability.

[eonist]

@phoenixeliot Yepp a restart of the app now and then is the temp fix for this.

[phoenixeliot]

@HebaruSan I actually only work with that one repo for almost all of my work (with another small private one open occasionally). I keep each atom window scoped to a single project in Treeview as well (I atom . in the project)

[maxbrunsfeld]

Hey everyone; I'm really sorry this went unaddressed for so long. It is fixed on master and will ship in Atom 1.22.0 (and 1.22.0-beta0 if you're on our beta channel).

The way we solved this was to introduce new native APIs for refreshing the git status on a background thread; that way we don't need to spawn a child process.

[wassname]

Thanks for all the work making it async!

FYI: I've found that even the new async git api can cause freezes if I have a large git repo. (I know this because when I do a cpu profile in 1.23.3 it traces it to getDirectoryStatus). So I'm still using the workaround. Other people who still have problems may want to do the same.

[zokker13]

Feels bad to know that the async library seems poorly implemented :(

[maxbrunsfeld]

Hi @wassname, thanks for the report. The function you refer to is unrelated to the code path that I made async. It’s part of the tree view package. If you could record a JavaScript cpu using the dev tools while this is happening and open a separate issue, that would be useful.

[wassname]

Ah I didn't realize that it was from the tree view, cheers for explaining!

In that case I should check my disc read performance etc before I report it.

[kravlost]

Glad to hear this is fixed but I moved to MS Code in the meantime as it was unusable, sorry.

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!