Why is Atom so slow?


Hey guys. Atom is slow because we haven’t finished optimizing it yet. It’s going to gradually get faster in a number of ways, but it takes attention, profiling, redesign of certain components, etc. I was worried early on that using web technology meant that Atom could never be fast, but experience has shown me that there’s no fundamental constraints imposed by web tech that we can’t overcome. It’s just a matter of time and effort.

If Atom is too slow for you right now but you’re excited about our other objectives, I urge you to check back every couple months until it’s fast enough. We will get there.

Archived FAQs (see FAQ category for all current FAQs)

I also have some thoughts! :wink:

So, there is a community of people who are well versed in creating “web apps”. They live and breathe this kind of thing. To them, having an editor that’s a web app means they instantly feel at home, with a cozy feeling. They also know how to hack it.

Another aspect is that web apps do make certain things pretty easy, such as styling via css. For example, the cursor is a DOM element and you can style it via css. Instead of blinking, you can make it pulse, by using css animations. If you build an app a different way, then you have to program such things in. Here, you can edit your personal style file to change the cursor appearance.

Now you can say who needs pulsing cursors (I don’t), I’m just using the example to show how text editors and presentation are not that far apart.

Because it’s easy to display stuff in a web browser, it’s also easy to display such stuff in Atom. For example, there is a markdown preview package for Atom that just compiles your markdown source code into HTML and then displays that. Little code required.

Do you need such fancy stuff in a text editor? Well, consider the preview-latex package for Emacs: it converts LaTeX source code for formulas into images of the formulas and lets you see the images instead of the source code. When the cursor moves into an image, it is “exploded” and you see the source code instead. I’d say that makes editing a LaTeX document with lots of formulas much easier. Atom can do the same. Of course, the user community is different, so I’m not sure might have that itch to scratch it.

How about on-the-fly rendering of Javadoc or JSdoc comments so that you can actually read them easily while browsing the code?

You mentioned that UE can be extended, but the extension is not too deep. That’s the point. In Atom, extensibility goes very deep, right into the core, and then out the other side. I also looked at Sublime. It’s got nice extensibility in Python (which is a nice language), but it also just scratches the surface.



Reading though the above, it strikes me that there are two conversations happening:

  1. There is a general complaint that Atom could start faster or be more responsive.
  2. Some users are experiencing slow performance that renders the editor unusable.

I’m concerned that issue 2 might be lost among the general debate over issue 1.

On my Xbuntu 14.10 install of Atom 0.186.0, there is an extraordinary lag between keyboard or mouse actions and UI response. Selection is typically 1s behind the cursor, key input appears 0.5s ish late and mouse scrolling lags 1-2s. It strikes me that this cannot be normal for users of Atom and that it must be a problem with my specific configuration.

A comment above rang true - the poster mentioned they had a similar problem with Chromium. I also had similar performance problems with Chromium until disabling the “Use hardware acceleration when available” checkbox in Settings. With hardware acceleration disabled, Chromium runs perfectly on my machine.

Another metric - scrolling or typing in a foregrounded Atom window causes it’s CPU utilization (reported by top) to hold at ~99%.

If anyone can help me find a way to disable hardware acceleration in the Atom Chromium build, I could at least give it a try and see if the problem resolves. I’d also be happy to supply any further information that might help.



It’s in the general settings section of Atom.


I’ve seen that in a screenshot (it was under “Tab Length”), but it doesn’t appear in my build.


What version are you on? If you did a custom build, may I ask why? (I’m nosy).


I access settings with “Edit” > “Preferences”. Also, I should mention that I am running atom with the --safe flag.


Version 0.186.0 - no custom build, just the atom-amd64.deb file from the atom.io homepage.


I looked on my bog-standard v0.186.0 at work and the option wasn’t there. It looks like it was removed here:

Which would indicate that it has been this way since v0.183.0.


Ah, okay. Thanks! I’ll try the 0.182 release.


The hardware acceleration checkbox in Atom 0.182 didn’t make a difference.

However, I just upgraded to Xbuntu 15.04 daily build with Atom 0.187. I’m not sure which fixed the problem, but Atom is now nice and fast!


I’d like to apologize. The posts where I cavalierly discussed rebuilding Atom from scratch were beyond negative – they were just rude. I don’t think I understood the full context of the project. In any case, I apologize.


Thanks @JoeArizona, apology accepted. I’m glad to see that you stuck around and got a greater perspective on things :smile:


I have noticed it is extremely slow when launched via git commit message editor. I have been using sublime until yesterday and sublime would open up instantly where atom would take a few seconds to pop open. I have another instance of atom running when I commit messages, so I am assuming it is not launching a new process.

My git config for editor
editor = atom --wait

$ which atom


Wow. Looking back, one couldn’t have imagined how fast things would go with Atom in just four months. Great work definitely!

It’s now close to becoming my primary editor, although I do have open-emacs up in its sleeves!


Just to add a quantitative note on the current state of Atom on Fedora 22:

Atom v0.201.0 on Fedora 22 eats anywhere between 30% to 100% of CPU and 20% of 8GB when idle. It also constantly accesses the disk when idle, making the machine essentially unuseable. When I force quit it it leaves Firefox consuming 25% of the CPU when idle! Firefox does not do this until Atom is run. Fortunately FIrefox does not access the disk after Atom is killed so at least the machine comes back to a useable state.

Does anybody else have this problem and is there a workaround? Older versions of Atom show the same behaviour. Thanks.


And this is in safe mode?


Actually I have no idea! I tried glancing at the script stored at /usr/bin/atom but could not say for sure. So I guess it is whatever the default was set to for Linux?


You can run Atom in Safe Mode (which disables all third-party packages, among other things) by closing all instances of Atom and then opening Atom with the command atom --safe.


So I started it in safe mode and observed the same behaviour (but there is a happy ending). I noticed that even though I did not interact with Atom in any way the CPU amount was fluctuating between 20% and 100% again and the memory was slowly increasing from 2% to 13% (looks like a memory leak to me). I then noticed that there were 2 Atom processes, so I ‘kill -9’ the badly behaving one. Now I have what seems to be well behaving instance of Atom running!

Fingers crossed, hope it works as intended!