Atom: Frequently excessive CPU, memory consumption
Over the last few weeks I’ve noticed that Atom is frequently consuming what I would consider a fairly large amount of resources. It seems that just having a single window open, without even openning any tabs/buffers, will predictably open a couple of (usually two, sometimes three) "Atom Helper" processes which will between them consume ~100% of one CPU core worth of activity:
Sometimes this is heavily weighted towards a single Atom Helper process (~100% on one, single digit percentage on the others—as the above screenshot shows), but other times it’s split fairly evenly across a number of Atom Helper processes (e.g. ~30-40% on each of three processes).
As you can see from the screenshot, this is occuring with the github/github repo, with no files open. I don’t think it’s due to any search indexing/scanning processes or anything that I imagine happen when you first open a directory, since the activity continues predictably even if leaving the window open for like 20 minutes.
The memory consumption is also frequently the top item in my list (again this is without having any buffers open).
FWIW I’ve tried leaving Atom open with no open buffers in much smaller folders/repos than github/github too, and there doesn’t appear to be any discernible difference in CPU or memory consumption.
I’m not really sure if this issue helps at all, since it doesn’t really suggest a concrete bug or problem that has a clearly actionable fix. I’m sorry about that, but I felt like this was worth bringing up :gift_heart:
cobyism
All 101 comments
I also just noticed that Atom seems to be chewing up a ton of juice too. I have ~50% of my battery remaining, and my OSX is saying that’ll only last ~35 minutes based on current consumption rate. This feels excessive.
cobyism
on 3 Apr 2014
I've just fixed a memory leak in the whitespace package that could be causing the memory consumption and possibly also the CPU due to the extra overhead for the garbage collector. Should be out with the next release. When memory is excessively high, it would be great if you could take a heap snapshot and post a screenshot of the top objects. We don't have the ability to save snapshots yet.
nathansobo
on 3 Apr 2014
@nathansobo Ok cool. I’ll post a snapshot next time I see it revving up :+1:
cobyism
on 3 Apr 2014
FWIW when I opened my computer up this morning, my memory consumption for Atom is up to ~2.8GB (1.57GB + 731mb + 522mb over three Atom Helper processes):
Here’s a screenshot of the current heap snapshot:
Is that the kind of thing you’re wanting?
cobyism
on 7 Apr 2014
Yeah. @zcbenz just added the ability to _save_ heap snapshots to disk, which will really help us dig in and figure out what's leaking. In this case it seems to be all arrays, which I _suspect_ is the undo history. What happens to the heap if you close your three editors?
nathansobo
on 7 Apr 2014
@nathansobo I closed that instance of Atom hours ago—sorry man! it’s hard to do live-debugging like this asynchronously :laughing:
cobyism
on 7 Apr 2014
I can confirm an excessive power use with the latest -git build on Arch Linux 64Bit. This is particularly painful if you use your laptop a lot mobile.
Please let me know if I can provide you with any more information that help to reduce power consumption on Linux.
orschiro
on 11 May 2014
I seem to be getting this bug whenever I open/close a file whenever I have a lot of tabs open.. Below is a screenshot of the dump, and I also attached a zipped version of the heap dump.
heap snapshot: https://dl.dropboxusercontent.com/u/95472295/Heap-20140603T130754.heapsnapshot.zip (10MB)
Is there anything else that I can provide to help you guys out?
Gercoli
on 3 Jun 2014
I've noticed this, too. I frequently see my memory going down to ~200MB on a 16GB machine. Looking in Activity Monitory, I can see two Atom helpers using about a half gig each, and dozens of Google Chrome helpers going ranging from about 650MB down to 14MB.
carlodicelico
on 2 Jul 2014
For clarity, the chrome helpers are chrome tabs, not atom. So atom is using
about a gig in your case.
On Tuesday, July 1, 2014, Carlo DiCelico [email protected] wrote:
I've noticed this, too. I frequently see my memory going down to ~200MB on
a 16GB machine. Looking in Activity Monitory, I can see two Atom helpers
using about a half gig each, and dozens of Google Chrome helpers going
ranging from about 650MB down to 14MB.—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/1827#issuecomment-47730554.
benogle
on 2 Jul 2014
Oh, right! I keep thinking the Chrome stuff is related to Atom. I still see the main Atom instance and 7 Atom Helper instances, though. Tallying it all up it looks closer to 2 gigs. Still a lot for a text editor although to be fair, I have 3 Atom instances open with multiple tabs and panes in each. So, on second thought maybe it’s not that bad…Â
--Â
Carlo DiCelico
On July 1, 2014 at 22:25:25, Ben Ogle ([email protected]) wrote:
For clarity, the chrome helpers are chrome tabs, not atom. So atom is using
about a gig in your case.
On Tuesday, July 1, 2014, Carlo DiCelico [email protected] wrote:
I've noticed this, too. I frequently see my memory going down to ~200MB on
a 16GB machine. Looking in Activity Monitory, I can see two Atom helpers
using about a half gig each, and dozens of Google Chrome helpers going
ranging from about 650MB down to 14MB.—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/1827#issuecomment-47730554.—
Reply to this email directly or view it on GitHub.
carlodicelico
on 2 Jul 2014
I've not experienced too much issue with memory consumption but CPU usage is excessive, it sucks the battery life out of my rMBP. Even deleting all packages and disabling the spell checking package made no difference. Highlighting large areas of text caused problems near starvation conditions. Quick typing also caused large increases in CPU usage.
paulbeattie
on 21 Aug 2014
I also like to report that CPU usage feels quite extraordinary in many circumstances. My rMBP gets, at best, 4 hours of battery life while running Atom, and 6+ otherwise.
For instance, scrolling through a file puts approximately this much "Energy Impact" load on my system, according to ActivityMonitor:
Textmate: 15-20
Sublime Text: 30-50
Atom: 100-140
And just sitting idle, with a few tabs open:
Textmate: 0
Sublime Text: 0
Atom: 5
I realize that TM and Subl are native, and Atom is a JS-based app with all the overhead of the VM (etc.). But this is still egregious, given that Atom uses more energy than any of my browsers, by a factor of 3 or more.
ivanreese
on 18 Oct 2014
Atom by default uses hardware acceleration (i.e. the GPU) for most of its rendering, and Chromium shifts this onto the discrete GPU (assuming you've got a 15" rMBP) which results in the "significant energy" issue. I work around this by using gfxCardStatus; when on battery power, I force OS X to only use the integrated GPU instead of being allowed to swap between integrated and discrete. (Note: I also do this because of Chrome naturally exhibiting the same "problem").
thomasjo
on 19 Oct 2014
@ivanreese Yeah, I hear you. We are aware that we need to improve in this area and are actively working on it. Keep in mind that most web sites you visit have significantly less intensive scripting workloads than what Atom is doing. The solution to this is to run less code more optimally. We've already made progress on this front but we have more to go. Part of the API freeze initiative we're currently pursuing is an effort to discard lots of code we don't need. We will continue this process until our energy impact is more in line with our competitors.
@thomasjo This was once an issue but I thought we resolved it. On my first generation 15" retina MBP Atom does not force a change to the discrete GPU. Are you sure this is still an issue for you?
nathansobo
on 19 Oct 2014
@nathansobo Just ran a few tests now and it seems you're correct, Sir; Atom no longer switches over to the discrete GPU. Jolly good! :speak_no_evil:
thomasjo
on 19 Oct 2014
A Atom Helper just needed 900MB ram and the Editor became unresponsive. Is there any memory leak since the latest version?
philipgiuliani
on 19 Nov 2014
@philipgiuliani There was indeed a memory leak that was fixed in v0.150.0. Thanks very much for the alert which prompted my investigation. Clearly we need something in place to detect these sooner, or just check periodically for leaking editors, buffers, etc. The serious churn in core is almost over, however, making this less likely in the future.
nathansobo
on 20 Nov 2014
Many thanks for this! :)
philipgiuliani
on 20 Nov 2014
Greetings,
im getting lots of atom helpers resulting to fork failed: resource temporarily unavailable on my rMBP 2013. quitting atom is the only way to solve it. any clue why do i have lots of atom helpers?
Hokutosei
on 27 Nov 2014
@Hokutosei, It might be helpful to see the flags passed to those Atom Helper processes. Can you post the output of ps -ax -ocommand | grep Atom? You may want to check that no sensitive information is included.
maxbrunsfeld
on 27 Nov 2014
Greetings,
oh, thanks for the reply. I hope I did not include sensitive information. [update: Atom Version 0.152.0 (0.152.0)]
piping it to uniq -c
448 (Atom Helper)
1 grep Atom
Hokutosei
on 27 Nov 2014
Greetings,
any updates on this pls? thank you
Hokutosei
on 28 Nov 2014
I've been having the same issue. Using ps ax | grep Atom and some experimental process killing, it looks like the process causing the problem at least for me is
/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --eval require('/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app/node_modules/coffee-script/lib/coffee-script/coffee-script.js').register();^Jrequire('/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app/src/coffee-cache.js').register();^Jrequire('/opt/homebrew-cask/Caskroom/atom/latest/Atom.app/Contents/Resources/app/src/task-bootstrap.js');
I have no idea what it connects to, but after killing it the editor tab interface dies but files can still be selected from the taskbar and edited/saved fine.
drumanagh
on 18 Dec 2014
I'm also having the 'fork resource temporarily unavailable" problem. I'll do the same grep thing when it happens again.
bigblind
on 11 Jan 2015
Is someone looking into this? I'm on Ubuntu and this is how Atom looks like after an hour or 2 of editing Markdown files:
stevenroose
on 5 Mar 2015
The work @nathansobo and @maxbrunsfeld are currently doing to fix #307 should reduce memory consumption as a whole.
Also, make sure you're on the latest version (Currently 0.186), as there have been several performance improvements in recent releases.
benogle
on 5 Mar 2015
I've recently noticed some absurd memory and processor consumption from Atom:
The above happened with no buffers open and only with default packages after running for about 5 minutes without any user interaction.
Interestingly, if I wipe my Atom config (rm -rf ~/.atom), the next time I launch Atom and it works off a freshly generated config, it performs well:
If I then close and re-launch Atom, it will start hogging resources again:
If I repeat the first step and wipe the config, letting Atom generate a fresh one, on next start Atom runs smoothly again:
The scenarios that result in Atom hogging up all the resources seem to have an additional process fork which is the culprit, when Atom runs smoothly there's only 5 processes for me, when it's leaking there's a 6th process for no apparent reason.
Killing this 6th process does not seem to affect the actual Atom shell/editor whatsoever, so it appears the issue lies with some process Atom is running in the background.
If I run Atom in the foreground atom -f it behaves the same way, interestingly if I end it with ^C, the Atom shell and all associated processes die, _except_ for this memory leaking runaway process:
If there's any further info I can provide to help, let me know.
wyqydsyq
on 27 Apr 2015
@pyrokinetiq thanks for the report. This sounds to me like it's related to https://github.com/atom/atom/issues/6437; the fuzzy-finder's indexing process is not terminating.
maxbrunsfeld
on 27 Apr 2015
I've got the same issue than @pyrokinetiq, seems like killing the excessive process does the trick. (Weird thing, I get 1 less process working than him.)
Vrakfall
on 28 Apr 2015
Have had the same issue as @pyrokinetiq for a few days now, very annoying.
Behaves the same, remove .atom and it works once, restarting it again and it starts to eat up ram + cpu again. 
EDIT: Issue https://github.com/atom/atom/issues/6437 is definitely relevant. Just like said in the comments there, running atom from another folder than $HOME works fine.
johan-bjareholt
on 28 Apr 2015
@johan-bjareholt: Try removing the leaking process every time you run atom instead of having to make a new .atom for each run.
Vrakfall
on 29 Apr 2015
@Vrakfall Like i said in my edit, as long as i run atom from some other folder than $HOME it works fine and don't have to rm -rf .atom. And starting atom in my programming folder rather than my home folder is my prefered behavior anyway. I simpy added cd $HOME/Programming at the start of the atom start script. I am running latest git on Arch Linux btw.
johan-bjareholt
on 29 Apr 2015
@johan-bjareholt Sorry, I didn't check your edit. It seems like a good idea, surely. I'm on Mac (for job purposes only, huehuehue) and running the latest release, that's why the behavior could be different.
Vrakfall
on 29 Apr 2015
Same here, 2 separated node processes were at 100% even after closing Atom.
cusspvz
on 26 May 2015
Similar issue: I have Atom helper using 2GB of memory on mac, with only a couple of python files open. I have to restart it regularly because of this. Such a shame.
jadnohra
on 27 Jun 2015
On the last days, this seems fixed for me. Just to be sure, i will be tracking this issue.
cusspvz
on 30 Jun 2015
I'm having the same issue on Windows.This is while opening a 17KB html document in one tab. It's making atom unuseable. The memory footprint was growing every second when I posted this.
kohbo
on 14 Jul 2015
This is insane......
RobinQu
on 29 Jul 2015
Happens to me to, but only if not in safe mode and only since the update to
1.0.3. Haven't figured out what package is causing this.
despairblue
on 29 Jul 2015
Shouldn't the label of this issue include something more severe than performance, it does not really seem to be a pure 'performance' problem.
jadnohra
on 29 Jul 2015
Can everyone confirm whether this is happening in safe mode? It's super difficult to debug this problem if it might be a package that's causing it.
nathansobo
on 29 Jul 2015
To add my input: I experience this very often lately: only one or two buffers open but atom + helpers use 2gb+ of ram and spin up processor even to 100% sometimes. Running this with chrome, the memory hog, and development virtual machine, the system becomes unusable.
I can't see the exact pattern of what actions did I do to get to this point, but I see this only after upgrading to 1.0 (did it at the day of release) and at around that time I also added nuclide and atom-ternjs. I also see very heavy load on my computer when I "installed packages" or "updates" section of settings.
Using Atom version 1.0.3 on OS X Yosemite (10.10.4).
markogresak
on 30 Jul 2015
@markogresak
the nuclide thing seems to be related to https://github.com/facebook/nuclide/issues/84, profiling shows that atom in that case reads in a huge amounf of files, see also https://github.com/atom/settings-view/issues/551
It can be fixed by installing nuclide manually, see the issues and nuclide's readme for this.
Ternjs goes completely insane on huge files. I have a js file with 1700 loc and have to kill the tern process every time. (btw ps and htop list the comand line parameters a process was started with, that way it's pretty easy to spot if ternjs is the script that make the atom helper process go crazy)
As for what I experienced, I had only a markdown file open, so I suppose it must have been another package in my case.
despairblue
on 30 Jul 2015
@despairblue thanks, I haven't checked nuclide issues. I've installed from sources and for now and it seems a bit better. I also disabled ternjs for now.
markogresak
on 30 Jul 2015
@nathansobo Even in safe mode this issue persisted for me. I haven't had it occur in the 10 minutes since I deleted my atom config, although it sounds like it'll only be a matter of time.
pwstokes225
on 19 Aug 2015
In my case the culprit seems to be the pdf-view plugin, although the real problem may be lying in chromium. When I reload a (tiny) pdf multiple times I run out of my 8GB of memory on OS X.
jadnohra
on 22 Aug 2015
Atom consistently uses more than 1 gigabyte of memory for me. This is too much.
panuhorsmalahti
on 26 Aug 2015
+1 even in safe mode ....
aroget
on 14 Sep 2015
Me too have encountered this issue multiple times.
It ocurres randomly even when there is only one innocent text file open in atom.
Memory consumption as high as ~2GB and almost 40%CPU.
I am using Linux Mint 17.2.
@pyrokinetiq That's a really sleek theme! Which one is that?
ManasN
on 15 Sep 2015
+1
coreybutler
on 22 Sep 2015
+1. Have tested few more times this could be a gpu bug as well. screen go haywire on my linux Nvidia driver. Is there way stop atom using GPU directly?
blessmurk
on 24 Sep 2015
For what its worth, this seems to happen more often when using yeoman's angular generator, (yo angular)....
aroget
on 24 Sep 2015
I've had to do alot of refactoring recently, which has required a lot of _cut_ and paste. I've had to restart Atom more frequently, leading me to ask "why now?"
When I run a heap dump, the events object seems to just grow and grow, suggesting a leak. I haven't been able to test extensively, but a quick inspection of the events object suggests the text snippet is stored in memory, but never seems to be released. I would expect a cut operation to copy the snippet, but when I cut another snippet of text, I would expect the content of the original cut to be released from memory.
My tests have been pretty unscientific, but suggestive. I am cutting/pasting an average of 40-50 lines of code at a time. When I cut several larger snippets in reasonably quick succession, say 400 lines of code, memory consumption appears to increase more rapidly (and remain high).
I've disabled every 3rd party plugin and several core plugins. Copy/paste appears to work decently... so I've been able to work around things by copying code and deleting it, then pasting it. It's an annoying way to work though a refactor though.
I've also noticed the Atom helper typically reaching 1.9GB according to the activity monitor, but my overall RAM consumption hits 31.2 GB (of 32GB). As soon as I kill the process, it drops to 20GB total consumption.
I hope this helps in some way.
coreybutler
on 24 Sep 2015
I suggest for those having more or less good steps-to-reproduce to open a new ticket including your system information and Atom version and mention this ticket number.
This issue has just grown too big and became a catch-all for unsatisfactory performance and is really hard to follow.
fbender
on 24 Sep 2015
I don't think so. Many of the messages here are constructive and making new threads won't actually solve the issue. As a linux user, I'm still experiencing that leaking process which uses all my cpu and eats around 100MB of RAM per second. I currently have no extension/plugin added and am using the last release version.
I have no mac to test anymore but when I was doing my internship, I had the same problem. And I started the internship in February. This gives you an idea for how long this problem is lasting. (Back then, I was using a lot of extensions)
Vrakfall
on 6 Oct 2015
@fbender +1
cusspvz
on 6 Oct 2015
This issue is forcing to stop using Atom. When can the fix be expected?
sahilbabbar
on 7 Oct 2015
Most of the memory issues I've passing through are related with _atom plugins_. Since atom v1 major release it seems much more stable. For those with troubles I advise to test Atom without any plugins or other themes rather than the default ones.
cusspvz
on 7 Oct 2015
i have personally tried with no plugins, or even installed themes - a vanilla install of atom. but the footprint is very large. this has been so for a number of updates. sadly i am not using it so much now because it does take up too much. so hopefully it can be fixed. its a big issue that many are having
these are my computer settings. on mac - if it helps
lewislepton
on 8 Oct 2015
@cusspvz Some people here and I are still experiencing the issue with a fresh install, not plugin or so.
Vrakfall
on 14 Oct 2015
@lewislepton @Vrakfall my Atom is spending only 200 MB of memory (74MB of compressed memory), here is more info about it:
Version:
Packages:
cusspvz
on 15 Oct 2015
@cusspvz What OS are you running?
Vrakfall
on 15 Oct 2015
exactly the same OS version and hardware as @lewislepton
cusspvz
on 15 Oct 2015
It's probable that the issue on Mac isn't completly the same. Maybe on Mac it only starts to leak when you get a fair amount of plugins when on Linux it leaks even without any of them. I can remember a while ago when I was using a mac, it wasn't leaking at the beginnings (also maybe because of the version). I've never had a Linux version that didn't leak. Also, Atom on Windows has always been good for me, no leaking on it so far (at least no obvious one).
Vrakfall
on 15 Oct 2015
@Vrakfall There are lots of variables that could lead to this behavior. On my case, and some of others here, it were plugins and with pre-v1 builds. Maybe you could help atom's team and yourself if you try, on a VM, with other distro or a fresh install of your current one and check if that happens.
cusspvz
on 15 Oct 2015
I have been experiencing a similar deadlock situation that has been reported here on El Capitan 10.11.1 (15B42). The first time I saw this happen was with Atom 1.0.19, but I have also seen this issue while using Atom 1.1.0. It's not a regular occurrence though; I use Atom every day and I experience this problem, maybe, once or twice a week.
OS/Computer Information:
I hope this helps in some way. Let me know if there's anything else I should provide.
non-binary
on 12 Nov 2015
I have also run into high cpu usage % and extremely degraded performance while my other apps are working smooth and fine. I have noticed after a few mins of working, atom gets choppy when typing, scrolling, changing tabs, almost to the point of freezing. If I change to a different app by clicking on it, like chrome for example, then move back to atom, atom then works like normal and smooth. After another 5 mins of coding, things will degrade again, I'll click on some other open app and again atom feels back to normal.
Open apps:
Atom 1.2.0
chrome
querious
slack
iterm
spotify
My system:
osx 10.10.5
rMBP mid 2012
cpu 2.6 i7
ram 16gb 1600mhz
graphics nvidia geforce gt 650m
coreybeaumont
on 16 Nov 2015
I too unfortunately cannot use Atom in its current state. After being open for just a few minutes, it sucks up all of my computer's RAM (I have a 2015 Macbook Pro with 16GB, and a quad 2.8 GHz Intel Core i7), and brings the computer to its knees. While Atom is open, each AtomHelper takes at least 1GB after a couple of minutes (so with 10 helpers we're looking at a lot of memory), and some of the AtomHelpers even persist in memory after I quit Atom:
I hope that this gets fixed soon, as I like this editor otherwise.
BigPrimeNumbers
on 30 Nov 2015
+1 ... a lot of Atom Helper processes keep chewing up RAM. Thanks for all of your hard work on this awesome editor, btw.
mattmcgiv
on 2 Dec 2015
Ok. Pull over everyone. You're all developers. If someone sent _you_ a screenshot of Activity Monitor, would that help you solve anything? Please stop submitting screenshots, and attach heap snapshots. Progress can be made on what is probably (several) real bugs, but without data no fixes can be made
anaisbetts
on 2 Dec 2015
The screenshot that triggered this last comment tells me: 1. the number of helper processes, 2. The memory distribution between them, 3. What part of that memory is judged compressed or compressible by the OS. Even if this is known information from previous screenshots, it either increases confidence in the frequency of the problem. Additionally, the tone of this last comment is detrimental to this page, especially the opening sentences.
jadnohra
on 3 Dec 2015
@jadnohra Ok, let me be more explicit - the screenshots tell nothing actionable to solving memory problems. Please submit heap snapshots, by going to the "Profiles" tab in Devtools.
anaisbetts
on 3 Dec 2015
@paulcbetts Does this help in some way?
naton
on 19 Dec 2015
@naton It's a good start! Looks like a child process is sending a bunch of stuff - now to figure out which one; maybe the linter?
anaisbetts
on 20 Dec 2015
Really interested in this, on the grounds that I often encounter (possibly rooted in the same basic reason) memory leaks when mounting a particular project that contains a good level of nesting (since npm -originated files) and quite a large body of text all in all. I've come across memory leaks no matter whether I use Atom, Netbeans or Sublime.
jpaulin
on 4 Jan 2016
Hey, guys!
Maybe I did something wrong, but my heap snapshot is 33.2MB. Is that right?
Anyway, I attached my CPU profile. What my issue is, whenever do a search in my projects the search starts to eat up my memory (slowly, but surely) and the CPU usage jumps up to nearly 100%, then (possibly) a cleaner starts up. The memory usage goes back to normal, but I must kill the search process from terminal to lower my CPU usage to normal.
I have an idea what causes this, I'll get back on this tomorrow.
Aekan
on 6 Jan 2016
I was having a similar issue, where Atom would slowly eat 2+ GB of memory, even when I did no text editing. (It probably would have kept consuming more, but I exited after a few minutes, before my system started paging.)
I was about to provide the heap snapshots as @paulcbetts requested, but I noticed that the heap included the filenames of _every_ file accessible from my home directory, including hidden files, caches, and executables from other programs. It also included files in subdirectories whose parent directory was only included as a soft link from my home directory. In total, I have 207,390 directories and 1,538,280 files in my home directory (from tree -al | tail).
Is Atom trying to read any substantial fraction of these? That seems disastrous. Even indexing them with tree takes several minutes.
On the other hand, I have no trouble if I'm in a clean directory:
mkdir foo
atom foo
(My observation doesn't explain @remisharrock's issue in #9006, or the copying and pasting problems above, but it's consistent with @Aekan's description. My heap file was ~60MB.)
System information:
OS: Ubuntu 15.10
Memory: 6 GB
Filesystem: ext4, on a HDD with 4K blocks
Atom: 1.3.2 (pre-built .deb file)
karldw
on 6 Jan 2016
Oh, for what it's worth, valgrind doesn't find any issues (if I'm using it properly), but I'm sure you've already looked at that possibility.
valgrind --tool=memcheck --leak-check=full --trace-children=yes atom --wait
karldw
on 6 Jan 2016
Hm, I successfully solved my problem.
I was trying to make the "Go To Declaration" work on a quite big project (751,5 MB with skins, tools, etc.). I used "atom-ctags" to generate the tags. It didn't work on such a big project as expected, so I uninstalled it, but I didn't delete the "tags" and ".tags" files.
This caused the leak when I used "Find in Project". Removing the files mentioned above solved the issue, everything works fine now.
I don't really understand what this means, but I thought any kind of information might be useful. ^_^
Aekan
on 7 Jan 2016
@karldw Does your home directory (or somewhere above it) happen to be a git repo?
joshaber
on 7 Jan 2016
@joshaber Nope
karldw
on 7 Jan 2016
I just ran into the same problem as @karldw. Two Atom windows with only one file open resulted in 1.6GB of ram being eaten. At first I thought it was chrome but oddly chrome with 4 tabs used a quarter of the memory of Atom with one file...
envygeeks
on 15 Jan 2016
Same for me, sometimes Atom burst RAM to ~1.5GB.
I always keep open my ~, maybe there are a lot of folder that cause a sort of re-index sometimes?
alessandro-aglietti
on 4 Feb 2016
@alessandro-aglietti, you can test by opening Atom up in an empty folder. On the command line:
mkdir new_empty_folder
atom new_empty_folder
@karldw starting Atom in an empty folder does seem to work.
gmish27
on 8 Feb 2016
Atom too much slower than Sublime text.
anhtuank7c
on 4 Mar 2016
I have noted that the excesive memory and CUP use hang my system a while after after searching into directories.
Maybe the search can be paginated or limited in some way to the first N results.
yucer
on 30 Mar 2016
I'm getting insane memory leaks for Atom Helper in Atom 1.7.2:
_(That's Process | Memory | Compressed memory | Threads | Port | PID | User)_
I seldom shut down my Mac, and have Atom constantly opened with 1-2 projects.
johanbrook
on 26 Apr 2016
Does the leak stop if you shut down and restart the Mac?
Zireael07
on 26 Apr 2016
@Zireael07 of course the leak would be stopped at that point. You've cleared the memory...
envygeeks
on 26 Apr 2016
Atom is awesome, but i'm sorry, i going to use Brackets or Sublime Text.
anhtuank7c
on 26 Apr 2016
I had the same issue with my meteor project, which generate the local build inside of app folder.
After install the plugin Atomignore and exclude the build folder [.meteor/local/*] from tree view, the issue seem to be gone.
faridescate
on 3 May 2016
Downloaded PlatformIO IDE, and started using Atom. Atom Helper at 100% CPU. fs_usage shows it scanning the filesystem (currently in my TimeMachine backup volume).
I did an Activity Monitor Sample Process (attached), and it is in git:
2285 Nan::imp::FunctionCallbackWrapper(v8::FunctionCallbackInfo<v8::Value> const&) (in git.node) + 131 [0x10ca20c75]
2285 Repository::GetStatusForPaths(Nan::FunctionCallbackInfo<v8::Value> const&) (in git.node) + 420 [0x10ca1e150]
2285 git_status_foreach_ext (in git.node) + 41 [0x10ca81338]
2285 git_status_list_new (in git.node) + 1089 [0x10ca80e0d]
2285 git_diff_index_to_workdir (in git.node) + 349 [0x10ca3a07e]
The sample process took 2285 samples, and displays a tree of stack traces. Each line shows the number of times the frame was active.
The only thing that I would mention is that I have a git repository at / (root) so that I can track changes to (for example) /etc. I also have a git repo at ~ (sample idea).
vallon
on 7 May 2016
Arch Linux x86_64, Atom 1.6.2
Not quite sure what happened for me. I had Atom open with 3 tabs(a yml file, a text cfg file, a settings tab). I was not actively using Atom for some time, the tree view was however not open on a project folder but my Downloads folder where I had opened a text file earlier. My system froze, I switched to a tty and killed my browser to free up memory and see what was using RAM, Atom for whatever reason was using over 10GB!
I closed Atom, opened it again(this time via terminal with --profile-start), about 300-400MB was in use, my 3 tabs restored with the tree view opened to Downloads again. Timecop reported about 5-6 seconds to finish loading the window. Memory usage was steadily rising. I opened a project folder that had one file in it, moved my tabs over and closed the original window. Memory usage dropped down to 300-400MB again. As I type however memory usage has been rising again, it's currently at 3GB, rising at 10MB per second.
Prior to this I had been using PlatformIO IDE for a few weeks, I disabled the package today as I do not need it for the time being. Although I've been having system freezes like this in the past week but unable to identify what was using the memory up(happened over night).
I have run atom --safe for a bit now and see no increase in memory usage. I assume this means a package of mine or some config that --safe ignores is at fault. Any advice on pinpointing the cause would be appreciated.
EDIT: Updated my packages and it seems to be fixed. I guess a package since my last update might have had a memory leak.
polarathene
on 13 Jun 2016
I encounter the same too much memory consumption issue in Atom 1.8.0 (rMBP - Yosemite )
I write markdown for 2 hour maybe and atom work slowly. This's the process sample file:
seanlook
on 11 Jul 2016
For most people it seems issue #3426 was the cause - the pigments package was the culprit.
If you're still experiencing this try removing or disabling that package and restart Atom.
methodbox
on 11 Jul 2016
I disabled the Pigments package some days ago to test, and haven't seen the enormous build up of memory (10-15 GB) as before đź‘Ť
johanbrook
on 14 Jul 2016
@lee-dohm Probably should lock this issue and send folx to a troubleshooting page
anaisbetts
on 15 Jul 2016
I don't use pigments and I am experiencing this since ever.
jadnohra
on 15 Jul 2016
There are an infinite number of individual reasons why Atom might be consuming too much CPU. The general categories are:
- Atom isn't designed to be a tiny native-code editor. If the ultimate in speed is what you're after, Atom probably isn't what you're looking for at least for now ... and possibly not ever depending on what you're expecting.
- An Atom package is causing a problem
- Atom itself is causing a problem
If Item 1 is the root of the problem, there are many other text editors that will probably suit your needs. Sublime Text is a popular one. vim is another. They were both designed with very different goals than Atom and if they suit your needs better, we're happy if you're happy :grinning:
If item 2 or 3 is more what is happening for you, then I invite you to take a look at the improved Atom Flight Manual. There is a tutorial on diagnosing runtime performance issues that will help you give us the information we need to track down these CPU problems.
So here's what I want people to do for us so that we can get these problems identified, root caused, and fixed:
- Determine to the best of your ability what actions or situations cause the problem
- Does the problem only occur in certain projects or in all projects?
- Does the problem occur right away or only after a long period of time?
- Does the problem only happen when you do something specific like "only when I use Find in Project and include a file mask"? Or is it more of a general thing like "any time I use find-and-replace"?
- See if you can reproduce the problem in Safe Mode. Whether or not you can reproduce the problem in Safe Mode, we want to help with the problem ... but we need to know where to start looking. Remember, the longest
git bisectsession starts with a single division of the problem space :grinning: - Use the runtime performance diagnosis tutorial to gather a CPU profile
Then, once you've done the above:
- If you can reproduce the problem reliably, open a new Issue
- Fill out the template
- Include what version of Atom you're running by including the output of
atom --version - Include what OS and version you're running Atom on
- Include as much information as you can about what actions or situations cause the problem
- Include a mention of #1827 in the new Issue so that we know you're following these instructions
- Include the CPU profile that you recorded in the new Issue
- If you need help reproducing the problem, go to Discuss, the official Atom message board and ask for help. There are plenty of people there (including myself and Atom volunteers) that will do their best to help you figure out what is going wrong so you can file an Issue to help us get it fixed!
We want to get all of these bugs nailed down, but like I said in my recent blog post, Issues need to be actionable. There needs to be a plan of action. This Issue doesn't have that, so I'm going to close it and ask people to work with me to help us tease out all the individual bugs from this mess.
Thanks for reading and I'm looking forward to seeing all the new Issues!
lee-dohm
on 15 Jul 2016
Related issues
thedaniel
·
132Comments
29e7e280-0d1c-4bba-98fe-f7cd3ca7500a
·
258Comments
snario
·
91Comments
alexwhitman
·
119Comments
csholmq
·
105Comments