AtomHelper High CPU Usage


Thanks @leostaples! Samples like these will hopefully help us diagnose this problem!


Exactly the same problem here. The Rdio plugin was causing the high CPU usage for me. It’s a shame. I like that plugin :cry:


I get the issue on both a rMBP 15" (2012) and a 21" iMac (2011) - both on latest Mavericks, Atom 0.80.0.

I do have the Rdio plugin, I’ve tried disabling it for now. I’ll see if that solves the problem. Though the problem doesn’t seem to have anything to do with pausing Rdio.

It’s worth noting that I only seem to get the problem when I have multiple Atom windows open.

EDIT: After a day of working pretty much solidly in Atom and no CPU hogging usage, I can confirm that it was almost certainly the Rdio plugin at fault. At the bottom of the plugin page, it says it’s “inspired by atom-spotify” - the atom-spotify plugin has this Github issue against it, so I’d guess the same bug affects both plugins. Opened a bug against the rdio plugin as well.


:+1: Disabling the Rdio plugin put Atom Helper in its place (rMBP)


For me, disabling the “Spell Check” package seemed to work. I noticed that the OSX spelling process was also very high CPU when Atom was hogging CPU, so I disabled that package and haven’t had problems since.


Ill try the above SpellChecker solution, and I will also try out the iTunes plugin I have installed. Any other solutions anyone has come up with?

By the way, 2012 MBPr on latest build of Atom as well as latest OS X.

Update: Doesn’t seem to really work. Here is a sample from one of the Atom Helpers:

Would like to also add that on a fresh install with no packages this issue persists, even when disabling spell check as well.

More "Atom Helper" process and cpu use very high!

This was happening to me with the Atom Spotify plugin. Disabling the equalizer took the Atom Helper cpu usage from 25+ to about 2


Same problem here, on fresh install (no Spotify plugin). Disabling spellcheck does not fix. Mac OS 10.9.2, on a late 2011 non-Retina Macbook Pro. Atom 0.84.

Sample of most-memory-sucking process:



Any news on this? It is pretty much a big deal breaker for me when my computer starts to heat up to crazy levels whenever I launch the program and open a C file.

I suppose that that little tidbit is also important, but this only occurs when I open a file. Having Atom open by default does not do anything crazy in regards to Atom Helper coming alive and spawning crazy CPU usage processes. Even an untitled text file while writing is completely fine and when I convert that file to a .c it still seems to be okay. However, as soon as I open a project I am currently working on and there is a lot of syntax highlighting, I get around 4 Atom Helper processes claiming 50 - 80% of the CPU each.

Hopefully a solution can be found soon.


I’m having similar issues. Just posted about it before I was redirected here (thanks to the moderator who did so).

I have a two-line coffeescript script open. Many helper processes using approximately 6.4 gig of ram. Also, Battery life has gone from 99% to 35% in the 70 minutes I’ve been messing with Atom.

rMBP, 16GB. Here’s a screenshot:

I hope this additional data helps in some way.

EDIT: Based on some other replies in this chain, I loaded disabled spellcheck, quit Atom, killed lingering helpers, and started it back up from the command line with ‘atom’

Anecdotally, it seemed a bit more responsive. Before, things would really lag. For example, scrolling through the list of packages was painful. After reloading, it was a bit quicker. However, as I worked with it I wound up with a large number of helpers all maxing out at around 850 meg. Many of which were sitting at 90-95% utilization.

Because someone asked,
I’m on a recent rMBP. 16 gig ram, 750 ssd. My display is at full resolution. I’m on mavericks.


Just upgraded to 0.90 and wanted to share some updated findings. As I stated in a previous post, I have a rMBP (16 gig ram, 750 ssd, best i7 model).

As before, I ran the activity monitor, loaded Atom, and brought up a simple coffeescript file (two lines). I ran the scrip using atom runner and the script plugin.

Before 0.9, my fans came on at full blast almost immediately. This time, they have not come on after half an hour. I call that a plus. Also, and probably because the fans aren’t running, my battery is draining at a much more reasonable rate.

As before, I have several atom helpers running. They all max out around 850 meg. They seem to be growing a lot more slowly than before, however.

Typing is sluggish. There’s probably a half-second delay between when I hit a key and when the letter appears on the screen. Same goes for running scripts.

So, from my perspective, it looks like some issues were addressed, although there’s nothing I can point to in the release notes for 0.9 that indicate that.

What’s everyone else’s results been like?


I’ve seen a lot of sluggishness in typing over previous builds as well — at least since 0.69.0. I’m on a 13" rMBP, 8GB RAM, 512GB SSD, i5. CPU usage overall doesn’t seem as bad, but the app still feels slow when there’s milliseconds-slow lag for each character typed. Even caret positioning (clicking or arrowing over) seems super slow.


So I have some good news on this front. I’ve been corresponding with the support folks at github on this issue, have sent a few heap snapshots, etc, and my issue with respect to the high processor usage / insane memory usage has been resolved:

My atom test environment was pretty simple. No packages and no git repository. The no repository thing is what got me. When there’s no repo, atom looks back up through the directory tree until it finds one. In my case, there was a repo at in my home directory. Not sure how it got there, but it was huge and included hundreds of files and folders. I renamed the .git folder and… I dont have this problem anymore.

Atom has been running for about half an hour now. My laptop is not on fire, my fans are not running, and it’s “only” using about 80 meg, instead of the 6 or so gig it was using before.

I’m not sure if this will help everyone else who has had this problem, but maybe it will.

We determined what repo atom was looking at by opening the developer tools and running:


Hopefully this helps.


@kevinsawicki, the github support person who helped me, went on to say that:

I’m going to change the task to stream the results back from the status command in chunks instead of sending one giant JSON object containing all the repository information, I’m hoping this will prevent the issue you are seeing where the processes never complete and hold onto tons of memory.

Having issues with excessive battery drain even when idle
split this topic #47

I moved a post to a new topic: High CPU usage when using keyboard to navigate


I also had a git repository in my home directory, and removing it also fixed my high CPU problems.


I don’t seem to be getting this issue anymore. However, I did notice that making your project folder a repository makes Atom perform a lot better. I had a javascript file about 200 lines long, and Atom was starting to get sluggish with it — there would be a noticeable typing delay, for instance, and this persisted after I disabled various plugins, even though CPU and memory use were not unusual. I started a repository in my project folder and everything was smooth again.


That’s odd. I wonder why that would be the case? Has anyone else experienced this?


I’m running v0.100.0 and I’m still getting this issue. It seems that the more tabs that are open, the worse the issue becomes to the point where atom will just completely lockup.

I’m NOT using keyboard navigation, I don’t have a git repo in my home directory (although this project that I’m working on IS a repo), and the point where it locks up the most often for me is when I’m opening a file that is part of the repo (usually php or html)…

Has anyone discovered a fix for this?


If you can follow the instructions to save a heap snapshot and attach it to this bug:

That could help the Atom team figure this out.


I’m having the same problem, latest Atom, MBA, Latest OSX. I did notice spellchecking was also very high, both > 70%.

So I turned off the spellchecking, and will report in later.