I continue to want to like Atom, and I try it out several times a year. Just updated, and see that it still has big performance problems on my system. I currently have BBEdit and SublimeText open for real work, and these are apps the have been running for days.
Here 100% would represent full usage of a CPU core:
BBEdit:
15 files open (various types/sizes)
76MB RAM
< 2% CPU
1 process
25MB app disk space
SublimeText:
10 files open (various types/sizes)
169 RAM
< 2% CPU
1 process
27MB app disk space
Atom
1 small Markdown file open
> 1.2GB RAM !!!!!!
> 85% CPU
7 processes
205MB app disk space
Just sitting in the background I am seeing Atom's CPU and RAM usages fluctuate wildly. The numbers above are the LOWEST I observed.
I will spend a little time looking into why this is happening. I certainly could be related to some add-on package that I have installed, but I don't every recall seeing BBEdit or SublimeText behave so poorly with all of the customizations I have thrown at them.
Update: added disk space for base app. Even with a 500GB SSD, Atom would make me think about its value vs space usage.
Update 2: the system specs. 2011 MacBook Pro 13-inch, 2.3GHz i5, 500GB SSD, 16GB RAM, OS X 10.11.2
Update 3: performed a clean reinstall of Atom, removed all third party packages, removed preference files, disabled Markdown preview. Atom is still using over 80% cpu and greater than 1GB RAM with one short markdown file open
Well, I kept digging and ultimately found a very long running issue thread[1] that mentioned having a .git directory in your home directory can cause high CPU.
Removing the three year old and accidentally created ~/.git directory and restarting Atom fixed the problem.
So now I will give Atom a deep new look.
Still, I am a bit perplexed, this is an issue that has been reported for nearly two years, and has not been fixed. I am not sure about the technical nature of the problem, but I think Atom, is trying to digest my entire 340GB home directory. Assuming that this is desired behavior, there should be at least a warning at launch about the issue. I am sure that MANY people have accidental ~/.git folders, and have a bad experience with Atom. At the vary least, it should not have taken me a couple hours of digging to find a solution buried in a GitHub issue.
While this fixes the issue on my MacBook, I am not sure about the Mac Mini, which I don't think will have a .git directory, but I will check later tonight.
That's surprising and sort of disappointing to me. I _just_ (within the last week or 2) was setting up my $HOME to be .git controlled...and was thinking "Maybe I should give Atom another shot"
That's good to know, next time I'm evaluating whether to switch text editors (which happens plenty) - I'll have to keep that in mind (or more importantly try and not discount Atom immediately because 'Oh yeah, doesn't it have a problem with $HOME/.git?')
Of course Atom is not the lightest editor out there but your figures are really strange: I'm using atom for one year now with dozens of installed plugin, currently working with more than 10 files opened at the same time with an up-time of 17days and I've never seen anything like you.
except one notorious bug when trying to open minified javascript files of hundred kB.
That's weird to have such a difference performance-wise between users, because it's based on chromium which does not suffer plateform specific performance drops I think.
For me the biggest problem here is the high CPU usage when the app should be idling. That KILLS battery life. I would not accept this behavior from high end video software, I certainly will not accept it from a text editor.
Following that the high RAM use can lead to swapping which will impact performance and battery live. As I said above after a clean install, and with just one short markdown file open, Atom is now using over 2GB RAM and Climbing. Fortunately, I have 16GB RAM on this system, otherwise I would already be swapping.
BBEdit and SublimeText never tax the CPU unless I am working with extremely large files, or doing search & replace on a huge number of files. I often will have 50 to 100 files open for days in these editors.
I like the evolving ecosystem of Atom, it now looks to be about on par with Sublime, and I can see that it will soon over take Sublime on that front. But it really need to get the resource utilization under control.
To be fair to Atom, I also tried installing it on a Mac Mini with an almost clean Mac OS X 10.11 installation. I had similar problems.
> BBEdit and SublimeText never tax the CPU unless I am working with extremely large files […] it really need to get the resource utilization under control
Neither does Atom for most users. It's not just n problem of «resource utilization», you're clearly facing a bug … Maybe you should consider submitting an issue (https://github.com/atom/atom/issues)
I see a number of current CPU related issues for Atom. I will look into using the performance diagnostic tools and see if I can contribute any new insights.
Again, I am see the issues on admittedly rather heavily customized workhorse MacBook (lots of Unix level tweets), AND on my stock Mac Mini. So I don't think this is a case isolated to just me.
I've had this happen too. For me, disabling a continuously-fading cursor plugin stopped most of my troubles with high CPU. Still kind of ridiculous that to animate the color on a few dozen pixels constantly took so much CPU in 2015, but I'm guessing it was forcing redraws or something. Note that this was on an rMBP with integrated graphics if that matters.
Atom Helper sometimes gets a mind of its own and runs rampant on the CPU, sometimes eating 100% of a single core even an i7 2015 MacBook Pro. Quiting Atom doesn't seem to stop Atom helper. It takes firing up the Activity Monitor and quitting them. It's ugly but it works.
Just tried VS Code, because I was curious... It seems to be using around 230MB of ram, and almost no CPU with a single file open... I was surprised how much better it worked compared to some of the other browser/nwjs/electron based editors. It's become my daily driver.
I am watching VS Code too. At the moment, Code's eco-system of add-on packages is missing too many tools I would want on a daily basis. However, I like the strong progress and road map, I could see Code being my go-to editor in the next year.
Actually, it has been a few months since I last checked on VS Code, I guess I should give it a spin again.
I use many of the features of Anaconda Python IDE. I know that better Python integration is high on the list priorities for VS Code, so I think this may happened.
I tested out VS Code, seemed nice enough. Hopefully it'll get the tight integration with Git that Atom has. I have a love / hate relationship with Atom right now.
If true it's somewhat disheartening to see that newer companies are still carrying on the tradition of limiting a product (not that Atom is a "product" per se) in favor of promoting another one. I think there's a name coined for it but I can't recall it at the moment.
Weird. I don't get that on my system. Memory usage (according to top) is somewhere around 200 - 300 MB, cpu usage runs somewhere around 25% of a single core (on an i7).
The only time I get real lag on my system is when I'm opening a really, really large and minimized / mangled javascript file. Occasionally I get problems with the minimap or linters on very long files, but I have started regularly working with source files in the 5k - 10k lines range. I inherited and am refactoring and breaking down some monolithic stuff into more modular code, so there's a lot of tabbing around and copypasta in addition to regular coding, and atom's been responsive.
The thing I like about atom is that there's a pretty robust plugin ecosystem already.
It makes sense within the context of the Atom dream: to make a completely customizable editor, down to the pixel.
But Emacs has almost the exact same dream: to make a completely customizable editor, down to the character-grid cell.
This one small difference gives it way more performance, without much loss in my opinion.
Atom is extremely bloated in every sense of the term. It's bloated in CPU, in memory usage, in files, in libraries, in dependencies, in overall performance, in everything.
All because it wants to be customizable on the pixel level, rather than the character level.
I wish a new editor would arise to actually complete with Emacs. I hate this piece of junk editor, but it works, and it gets the job done.
I don't think pixel level customization is a major factor in bloat or performance. Doing it on top of a browser is what adds the majority of the overhead IMO.
How come Atom is slow for so many people? Visual Studio Code is based on Electron as well and doesn't seem to have that.
I tried VSCode for TypeScript and it was very smooth, not as good as Pycharm for my usecase though
Completely out of curiosity I checked the status of my emacs server:
189 opened buffers (4 terminal sessions, rest are mixture of Ruby, Clojure, Javascript and Elisp files)
< 1% CPU
2 processes (server + attached editor)
no idea about disk space probably around 100MB
It has zero effect on my workflow though. I can run Chrome, Safari (for testing), Outlook, Slack, music streaming, etc. without any slowdown when developing with Atom.
Edit: Just checked, after using Atom for two days straight it is currently occupying 80MB of ram. Anecdotally, the claim that Atom is a resource hog is actually wrong.
I'm on the same boat, as much as I'd love to love Atom, I keep installing it anew with every release only to get disappointed by the performance. Shame because it's an otherwise great editor.
I think the markdown-preview plugin may have issues because once I get to about a 400-500 line file it pegs my i5 at 100% CPU and takes 5-6 real life seconds to enter a single character.
This is on Linux. Other than that, I would say performance is reasonable on all projects I've worked with (couple hundred files in a folder while actively editing a handful at a time).
Thank goodness. I was beginning to think it was just me.
I'm in the exact same boat. Other people tell me they like Atom and every single time I try to use it my system thinks I just set a vampire on the CPU.
That seem pretty atypical... I'm trying everything I can think of, and I can't get the CPU above 40% utilization (and that was just a temporary spike while searching a massive directory of files).
For me, Atom idles at 0.5% CPU. 10 files open, 130MB of memory being consumed.
I'm fairly sensitive to slowness for an editor. Earlier versions of Atom had too much noticeable lag. Recently, though, it seems pretty performant.
Here is a way to reproduce an issue. Put syntax highlighing on discover.
Open a 1000 line json file. Most of the issues are on syntax highlighting. The editor has a very bad way of inplementing this, based on it always crashing or timing out.
The edit window closed, but to be fair I need to mention that the from 1.3 - 1.4(the new update), I opened the exact file I had significant problems with.
The editor used to bottle neck, hang, and usually would just quit after being non-responsive.
This has been fixed. The editor would take ~45-60 seconds (I timed it when i logged the issue on github). It now takes ~3 seconds. Sublimetext comparatively, is a bit better at <3 seconds, atom takes about 3-5 seconds and shakes out the highlighting over another 1 or 2. In total, you can start working on the file in about 4 seconds which is a big improvement over never/1 minute.
Here 100% would represent full usage of a CPU core:
BBEdit:
SublimeText: Atom Just sitting in the background I am seeing Atom's CPU and RAM usages fluctuate wildly. The numbers above are the LOWEST I observed.I will spend a little time looking into why this is happening. I certainly could be related to some add-on package that I have installed, but I don't every recall seeing BBEdit or SublimeText behave so poorly with all of the customizations I have thrown at them.
Update: added disk space for base app. Even with a 500GB SSD, Atom would make me think about its value vs space usage.
Update 2: the system specs. 2011 MacBook Pro 13-inch, 2.3GHz i5, 500GB SSD, 16GB RAM, OS X 10.11.2
Update 3: performed a clean reinstall of Atom, removed all third party packages, removed preference files, disabled Markdown preview. Atom is still using over 80% cpu and greater than 1GB RAM with one short markdown file open