Why is Atom so slow?


That’s because it’s rather difficult to detect and pinpoint down to a specific package. What would be helpful is an easy way to measure package performance individually. But such a common denominator to measure won’t exactly be simple to find.


There is a framework in the atom/atom repo for doing performance benchmarking through specs:


So, if a package has specs, measuring performance of functionality should be pretty simple. And if a package doesn’t have specs, here’s yet another reason to learn to write them.


Ooh, I didn’t know about that. I shall investigate.


Hello all,

I just installed Atom and I spent about 10 minutes figuring how to set it up. It was awesome. I fell instantly in love and decided this would become my new text editor. To hell with the rest! This was it.

Then I opened my mounted drive, and everything got very slow and weird. I googled “atom editor slow” and came here. I don’t have any packages installed, but I did change the theme to Atom light because I code in inverted colors mode channelling Tank from The Matrix I (rip). I only mention this because I appreciate the dark color being default for those coders actually IN the matrix as it’s easier on their eyes.

Please make Atom faster whatever it takes. I love the idea of what’s going on here and I am a fan of everything but the fact it’s choppy. Either that or someone suggest a workflow for me where I can edit my server files without using my sick ass sshfs command.




The original slowness complaints that spawned this thread have pretty much been fixed.

Have you tried running atom on a fast internal drive?


Atom still has performance problems with non-internal, non-solid-state drives (and maybe even some file systems like NTFS?). Try updating larger packages like Omnisharp on a spinning disk and watch node slam the disk and max out a processor core writing lots of small files.


Im daily user for git hub atom. i found it best , using latest version with latest packages versions.

But im getting problems like.

When opening Atom first time it takes around 20 seconds to load.
Only atom menu appears and rest of window hangs until all the atom
loads.When i apply some package like atom beatify to some page whole
window stops responding. Sometimes i get error like editor is not
responding. Close or wait more. I have to wait more in order to continue
with work.

There should be a bar when the core atom features loads the window
should be working properly and when loading the each of the installed
packages it should display in status bar like 10 of 20 packages loaded
and editor should be working behind in order to continue work and when
package loads all features start working in backend of editor etc


I’d like that too, actually.
It would give people a way to assess which part of the launch experience is holding them up.


I do like what Atom is aiming to do, it is cool be able to hack on internals. I link npm from source and patch small issues often related to Windows, so I get that sentiment. Maybe after the current goals are met, Atom will shift gears to performance. I use atom on 2 Windows machines and a maxed out current Mac retina 15". It is noticeably slower on Windows for me, particularly on a 6-core i7-3960x (not that it feels particularly fast on Mac). The drive is a Samsung 840 Pro 512GB. I’m on a fresh install of Windows 10 now, and while the situation is not nearly as bad as it was on 8.1, it will still totally lock up the settings page when it loads and I will get slow responsiveness when trying to navigate plugins, etc. Feels like something is trying to handle I/O synchronously. On Windows 8 it would regularly freeze up good sized projects for 30 second periods, haven’t used enough on 10 to comment, seems like most things run faster in 10. I haven’t gone too wild on plugins, I use the VIM plugins and haven’t received any notifications of the plugins bombing or slowing the editor. It is slower most the time than Visual Studio with 8 projects open (which is a lot slower than VS code). Maybe its multi-threading issues with lot of cores?

Is there something inherent to Atom’s node-only architecture that goes against writing native modules to handle low-level functions and treat them as normal JavaScript dependencies? I would think that with GitHub being the primary git provider, that the low-level goals for the project might tie closer to those of git. If git was written in bash script, we wouldn’t be discussing Atom after all. I’ve tried to dig into the internals a few times but the coffee-script style (not syntax) turned me off to it. Maybe its a waiting game on Web Assembly to mature? I am not trying to be cynical, I use GitHub constantly and application responsiveness is the most important thing to me. I’d be happy to profile / monitor it in process explorer and try and figure out what areas are choking, but also not sure if its worth the time if the necessary bits to solve the problem would not be accepted… and the coffee-script.


Actually it is node, specificially npm, that allows native modules. It is of course a larger effort to write native code.


Plus, it would defeat the idea of having an editor that is hackable using only web technologies.


also there should be any way to set processor affinity for github atom editor.
for windows 7 / 8 or other OS to set which specific processor core should handle this task.
it may make atom editor faster loading time if people know how to set and i think mostly good developer will easily do that.


Not to be contentious or controversial, but I just upgraded to 1.0.19 and Atom became basically unusable. 20 minutes from trying to scroll down a (180 or so line) file to rebooting because the spinning pizza wasn’t going away, and it was making everything else unresponsive. I even had a 15 minute nap (what else does one do while waiting for a code editor scroll down a file with nothing else to do on a Saturday afternoon?) That’s actually a first.

So… I investigated. Nuclide was the root of all my problems. I don’t know what it does, but it does it very slowly. Checking the list of features against what I use, and disabling the ones I don’t need, I found I’d disabled pretty much all of it. So I disabled the rest (checking the performance as I went along), deleted it and now Atom seems to be so so much faster. I’ve not seen a “Keep waiting/Close” dialog for over half an hour. Which is actually pretty good for my setup (oldish MacBook Pro)!


And the coffee-script… exactly. I love Atom, hate CoffeeScript.


I think the issues with latest Atom releases being slow may be related to latest builds of Chromium being super slow, at least on linux on integrated graphics (laptops)

I have been digging into these for the past couple weeks (I even had to switch to FF as my main browser for now)
There are a couple issues on Chromium bug tracker (easy enough to google up)

Has anyone else noticed slowdowns on Linux distros running on intel graphics by any chance?

PS: the easiest way to test this is probably by hovering over the top menus - seems like there is a major issue with repainting things that have css position: absolute/fixed applied to them. There is a very noticable lag that was not there before.

split this topic #136

8 posts were split to a new topic: Atom moving to JS?

Atom moving to JS?

Has anyone else noticed slowdowns on Linux distros running on intel graphics by any chance?

No, I don’t notice any unusual lag. (i7-4600U, Fedora 23)


Hmm… Could be debian-based distros then? Most of the issues I saw were on Ubuntu (I am on Mint which is also a debian-like distro)


I just signed up to leave a little comment.
After reading over 80 Posts I found out that people seem to struggle with performance issues from time to time.

I started using Atom yesterday on search for a decent (hopefully lightweight and performant) alternative to Notepad++ with maybe a few more features.
Im using Linux at the moment (Fedora 23) and thus Notepad++ can only be run using wine, which brings a few (not overly tragic but annoying) problems with it.

Looking through a lot of threads discussing editors and stuff I stumbled over atom and it kinda looks like a perfect editor for my needs. For the first hours (I coded over 10 hours the first day, using Atom), I barely experienced any problems.
The startup is “long”, of course but as Im using a solid state drive, the few seconds are not a big deal.
The performance in the editor itself and inside the menus is pretty snappy as well.

Today i started my system up and wanted to code. I installed a add-on (to highlight duplicate code words) and started coding.
The UI was really slow and sluggish from now. Barely acceptable.
Switching tabs (documents) had a delay of >1s and even navigating the cursor was delayed.
I tryed using the --safe parameter and it helped, the UI is pretty fast again, i closed it again and started without --safe.
Its still fast and im really puzzled what caused the slowdowns, when its not the plugin i installed.

Does anyone have input on this? There seem to be unfrequent slowdowns which last until i reopen the editor.
Im on a Intel i7 4720HQ with 16GB RAM, SSD, Geforce GTX 970m, so i suppose its not my hardware.

If i can give any more input I would gratefully do so.
Im no master JS Coder but I understand a bit of this and that so i might be able to investigate a bit deeper than an average user.

I hope to find any assistance and am looking forward to help solving the problem.

Also mails are welcome if you need anything.

EDIT: Im working on a sshfs mount!
Opening times are… okay, but that might be due to network latency.


I work on a sshfs mount all day. I don’t have any problems but my mount is on the LAN, not across the internet.

There is a core package that tells you how much time each package takes to load and initialize. It’s called time-cop. It won’t help with your exact problem but you should check it out.

The slowness on first run sounds like a fluke. Remember, one time is a fluke, two times is a bug. (grin)

Atom moving to JS?