Why is Atom so slow?


$0.02: Could it be related to Chrome trying to access the GPU? This appears to be the case in my situation (though I don’t know how to remedy). Details follow:

I just installed Atom on my Ubuntu 14.04 desktop machine and it looks phenomenal, but its performance is so slow that it is basically unusable. Also unusable on the same desktop is the Chrome browser, which I have since removed. Both seem to work fine on my laptop.

When running Atom, this process hogs the CPU: “atom --type=gpu-process”.

Note that when installing Ubuntu 14.04 on that desktop machine, I had to install proprietary (manufacturer’s) drivers instead of the xorg drivers.

Is there a config setting to disable or re-route GPU calls? I’ll be happy to try it if someone can offer direction.


Atom’s performance, especially for @nlenkowski’s examples, is no longer an “issue”. It’s a bug.

I’ve stopped using Atom for my git editor, it takes around a minute to perform git tasks. So using textmate, its immediate. I thought it was a bug as a git editor, until I notices after a LONG time, there was a window sitting on my desktop. What’s that? Oh, git. Damn.

I can handle some of the editing issues, but taking so long to start a new window with its files is painful. A favorite is a project search when you start your word with e and Atom hangs waiting until its found all the e’s. God. Again, I thought it was a bug, and was hung. Nope, just crunching e’s. Sad.

It is a bug. If it is not the highest priority, I’m outta here.

Coud we move its category from “support” to “bug”?


There isn’t a bug category. The support category, on the other hand, is described as:

If you’re using Atom and encountered a problem, bug, or issue.

Emphasis added

As for:

Atom’s performance has gotten some attention. Also, there is a section on performance in the official roadmap:

Only you can make the decision for yourself as to whether that qualifies as sufficiently high enough priority to satisfy you.


How about having a “preload” functionality like there is in many other software? Preload the atom shell and/or whatever else it needs, and then when you launch Atom, most of it is already in memory. I think Adobe Acrobat has something like this.


Here’s how you do it: take advantage of this wonderful issue tracker GitHub has, specifically made for Atom. Believe it or not, people do actually pay attention to it. Just make sure that you can provide specific examples of areas where it gets really bad.

Speed doesn’t bother me as much as most people, but that’s mainly because I have never had a truly fast laptop for any extended length of time. I first learned to program in Java (confusing, ugly language) using Eclipse (extremely slow, heavy IDE) on a 10-inch netbook with a whopping single Intel Atom core. Talk about slow.

Also, at around the same time, my leadership position in a school organization at the time (this was only 1-2 years ago) had me using a Windows XP computer regularly, which usually took 20-30 minutes to fully boot and another 5-10 minutes to log in, slow for even those standards. Atom actually feels faster than some things, and as I’m typing this, I’m using a 5-year-old Dell Inspiron, my primary computer. Nothing like having to, on occasion, xkill Chrome or Firefox because it hangs. I even remember, one time, having to xkill a stupid terminal window.

(I do suspect a perf regression happened in the rendering side in the last month, though, but I have been focused elsewhere, so I couldn’t get enough info to troubleshoot.)


@impinball Are you refering to the 26 currently open performance related issues on Github (dating back as far as last year)?


I thought one reason of feeling Brackets start faster is that: Brackets start up with these orders to show: show window -> show menu bar-> show editor view in separate times.
But Atom show window、menu bar、editor view in the same time.
Maybe Atom could improve this user experience, @kevinsawicki


I hacked atom and improve atom start user experience, see https://github.com/atom/atom/pull/4269
you can have a simple test by edit: /Applications/Atom.app/Contents/Resources/app/src/atom.js


Hope you can test my patch and vote for the pull request.


I record a screen video to show what I mean.
Before modify: https://drive.google.com/file/d/0B8i7zRr2bfCATG8wNDJmR3ZQb3c/view?usp=sharing
After modify: https://drive.google.com/file/d/0B8i7zRr2bfCAbG5sYnBiUG53LXc/view?usp=sharing
Combine both: https://drive.google.com/file/d/0B8i7zRr2bfCAaFBQbkxfT0JleG8/view?usp=sharing
Please notice the window show time with the dock animation down time and the editor view show time.
before modify: window show at 00:02, the editor view show at 00:02
after mofify: window show at 00:01, the editor view show at 00:02
Same start time, same editor view show time, different window show time, but make user feels quick and better.


I’ve publish a hack solution to make the atom start faster:
see https://github.com/atom/atom/issues/4293


I must say Atom’s startup time got much better lately. Great job!

I was a little disappointed with Atom back in the day when I created this thread beacuse it was advertisied like it’s the new great editor, comparable to Sublime Text (I didn’t use ST much but I remember it was very fast) and yet had such poor performance. Now I use Atom on daily basis on both Linux and Windows and I really like it!


The fun of use atom is to hack and learn.
Use open source and contribute to it :smile:


Updated, Also add a gist about the hack code: https://gist.github.com/yongkangchen/86f0284291584d0b7c78


It is convenient to use something like “emacs --daemon”?


that few ms, adds up, and on non-ssd it takes longer.

Here is something that works on speeding atom up for me:


That’s exactly how I felt. Everything else is great but the lag in typing and UI response killed it for me :persevere:

For this decade, I’ll probably stick with Emacs :stuck_out_tongue_winking_eye:

My primary machine is the latest Macbook.


Updated: http://blog.atom.io/2014/07/02/moving-atom-to-react.html
They have it before!

ReactJS VirtualDOM in Atom? (http://facebook.github.io/react/) or Integrate VirtualDOM in Atom (https://github.com/Matt-Esch/virtual-dom)

The fact that Atom is slow due to HTML DOM and CSS we all know, you guys should consider using or leverage with ReactJS VirtualDOM and do away LESS by fully utilize Javascript for styling and lot of perfomant…

Years ago, I’ve abandon Adobe Flex in Eclipse when it just hang with 1000 lines of code.

I’ve never miss Flash once ReactJS make it painless and so much clever tricks than JQuery.

Performance issue when .git is on root?

@alitavector tom is already using React for the Editor. I can’t find the reference right now, but the dev team didn’t see significant speed benefits from it. They saw some promising results at first, but after converting more and more of the editor components, the benefit became less noticeable.

See this comment from @nathansobo about why they have chosen to move away from React in the future:

Edit: Found the reference about the lack of performance benefit of using React:


Are there any updates on plans to make Atom perform at normal client software speeds? I’ve had the same experiences noted above. It takes an absurd amount of time to open on a Windows 8.1 64-bit Ivy Bridge Core i5 laptop with 8 GB of RAM. That’s not awesome hardware, but it’s plenty powerful enough to run a text editor snappily.

I had no idea it was built with CoffeeScript until last week. I had a hard time believing, or even understanding, the claim when I first heard it. To wit, are there any architecture docs? In particular, I was looking for some kind of overview doc, something that said “Atom is made of this and this, and built like this, and here’s a diagram of the core architecture and API.” It must be there somewhere – I’m probably missing it based on labeling or something.

When I read the “Creating a package” page, I was thrown because it never says what language packages are written in, which is crucial. I missed the .coffee file extensions that appear here and there, so maybe people are expected to infer that the logic would have to be written in CoffeeScript. It would help so much to say in the introductory paragraph: “Atom packages must be built in CoffeeScript.” and then proceed with the rest.

When I searched on “Atom editor slow” I found Loren Segal’s detailed post. I’m so disappointed that this opportunity was seemingly blown. Sublime is AWOL right now – no one knows what those people are doing anymore, if we’ll ever see any activity from them again, or why they think they can charge $70 for a beta that hasn’t been updated in over a year and has no apparent future. Atom was coming in at the right time. It’s a brand new, clean-sheet desktop text editor – how could it be slow? A 21st century text editor needs to be fast. We’ve definitely entered the era when something as simple as a text editor should be instant. Atom doesn’t seem to be using anything the OS is giving it, or what Intel is giving it, whether on Windows, Linux, or Mac. To make a desktop application based on node and Coffescript is an incredibly strange thing to do – it’s deciding in advance to not be fast, to not be a robust desktop application. Liking a language has nothing to do with whether you should build desktop applications with it. There’s too much of a trendy vibe and not enough engineering seriousness. Who’s in charge of the core work right now? Can we hire some people to fix it? The core needs to be in a serious performant language, like modern C or C++ that actually leverages all the things a modern OS gives it for speed and stability. Even Go would be a huge advance. A properly engineered core would be arbitrarily extensible with Javascript or CoffeeScript, and better yet, Python, Ruby, Julia, Dart, or even any LLVM IR. It’s extensibility could be extensible. It could be as hackable as you wanted it to be.