Why is Atom so slow?


And people who grew up around Microsoft Office are used to even longer load times as well as keeping the program open perpetually. Proper IDEs also tend to take as long or longer to load (though they don’t choke as much on large files).


I’m definitely the “on-demand” type, but I don’t mind leaving it running if I have to. Atom is such a great editor, but I was forced to switch back to Sublime Text recently because the machine I am using isn’t that great (it will be when I get my upgrades).

I’m glad to see that this conversation is still happening and that Atom-devs care. I know most of you are probably running on awesome 16GB laptops/machines with lightning-fast processors. You probably don’t even notice the performance problems like I do.

I can’t wait to try this 1.14 release to see if it helps in my case. Good job people, please keep it up :smile:.

edit: I wanted to say that tree-view is one of the biggest offenders for me, because I have a couple large project directories that I work with. I think sublime caches tree views somehow, which helps with this. I don’t know if atom does anything like that but it may be worth looking into.


It helps me for large files like 'translations with ~2k lines


I’ve seen that comparison before. These are some extreme examples. Another extreme example is search & replace on thousands of files, where Atom performs significantly faster than Sublime Text (and doesn’t freeze the entire editor while doing so).

I’m more surprised how Microsoft does it with Visual Studio Code. Personally, I think it’s rather ugly and it lacks many features of Atom, but yet it feels so much faster than Atom at times. I hope the Atom developers take a look at it every now and then to borrow some features or ways to improve performance.

Anyway, performance isn’t everything to me. I bet Notepad++ beats all those editors in performance, yet I would never go back to it (not for its Windows 95 look and feel alone!) Having developed packages for several editors, I must say that Atom, along with Visual Studio code, has one of the best APIs. And since its all Node, extending it feels limitless.


This did it for me. I’m guessing because Atom runs on Chrome. I had to disable hardware acceleration there too as it was all but useless on my MSI A6200 w/8GB ram & 250GB SSD. After disable both run like a river. Thanks!


I have disable hardware acceleration in both chrome and atome (opening with atome --disable-gpu), and it seems to do the trick for me too. I used to have slow character writing response and some drag here and there. I set atome on a new Alienware R3 2017 with maxed out specs, and I was surprised to see I would get such behavior. While I now get some fan activation sometimes (not much however), it now feels lighting fast when compared with the hardware acceleration on. Can somebody explain what is hardware acceleration, and how something supposed to accelerate is actually slowing performances? Is it normal that I get such problems with the new computer?

Thank you very much!


So I just did a clean install (made sure I deleted all the Atom related files and directories) of Atom 1.18.0 on my Retina MacBook Pro and currently have no additional themes or packages installed other than the ones which are pre-installed. A common suggestion to disable the spellchecker didn’t help. Is there anything I can do?

Edit: I was reading through another thread on the discussion board about 1.18.0 crashing due to some git/github related packages and so I decided to try disabling a few (git-diff, github, open-on-github) and now I’m experiencing no performance issues. I’m not sure which of those, if just one package or all were causing a performance hinderance, but the difference in performance is astonishing.


I see. Maybe if these three consuming routines were programmed in JuliaLang, they wouldn’t be so slow. JavaScript says it all… it’s a script, not a low-level performance language. Julia is both, breaks the two language barrier with its type system. With it, there’s no compile and runtime, only runtime.

It would make little sense, however, to design the core of Atom in Julia and the rest in other languages. Julia’s primitives are in Julia, so the whole of Atom could be made in Julia.

For a compromise on visuals, here’s a presentation of an also JS programmer at JuliaCon 2017 on web apps. I’m pretty sure the non-moving pretty parts could be made with JS.


You’ll probably have to shell out fewer versions with Julia.


Sounds like a great project.


Many countries start out with a language, and then have to train themselves on another to take them to the next era. I think Atom is one of these countries. It’s already lucky it knows English.


If you want to convince a group of people you don’t know (the Atom developers) to potentially have to learn a new language and port over a program they’ve been working on for 3+ years, and then convince the entire community of user developers that their packages would be so much better in this other language, when most users aren’t experiencing the lag that you believe is the compelling reason to move, the best place to do so would be on the GitHub repo.

Frankly, I think it would be easier to write a new code editor from scratch.


Hopefully the devs will convince themselves, about the core of Atom.

JS is not what makes Atom unique.


Gabriel Goh is also a JS and Julia programmer, who wrote this very nice piece on momentum. He’s accessible and a nice guy to talk to.




Just as an experiment de-activate “Automatically update” or any such call-home functionality you may find. Any added difference?

At times an anti-virus can be blamed for some problems. Miss-diagnostic can cause all sorts of havoc. Sometimes files are moved to quarantine causing internal exceptions on the software. Such is my experience with a coding environment that was designed using the .Net framework.

  • Dan


#####Feature Idea

Porting everything over to another language is going to hurt in the short to medium term. Even porting piece will hurt and support will be difficult.

How about having some of the elements of Atom (including some Packages) to be pre-compiled. Unavailable in its “script” form. Not everything needs to be kept at a changeable state for each time Atom is opened.

Maybe one should select and activate a package (add-on or core) for editing before it is made available. Perhaps this is what Microsoft does with Visual Studio Code.


This is already somewhat in Atom 1.17. See the V8 snapshots section of this blog post. There’s been talk of allowing community packages to opt-in but it sounds like the work needed to support that isn’t trivial.


1.19 (see release notes) also had a rewrite of the rendering layer, so even more improvements!


I am wondering, why is hardware acceleration enabled per default anyway? It seems like it wouldn’t add much in an editor with a largely static view image, and the slowdown it causes for some people, probably due to old gfx cards and/or buggy drivers, appears to be significant.

I know Chrome itself already has a blacklist for problematic hardware. However, maybe hw acceleration use in Atom should be restricted to some sort of whitelist of tested hardware where it isn’t only known to run, but actually known to provide any sort of tangible performance benefit?