Why is Atom so slow?

JS with V8 can reach near C performance, so it should not be this slow at all. My two guesses are:

  • DOM manipulation is slow. I don’t know how many packages are doing this kind of labor, but it could be affecting the overall performance.
  • Packages are not performing in background. It appears when some package mess up and consume a lot of resources, all the other packages get affected by it. Good old monothread js application. So this could very well be the main bottleneck, since Atom is composed of a lot of packages.

I think it is possible to make Atom faster, but it would probably require some remodeling of the package execution arquitecture.

@hugollm how would we go about testing those assumptions?

1 Like

I do totally agree with all things you mentioned, consider my reply as a duplicate post of emergentcypher.

Sublime Text vs Visual Studio Code vs Atom Performance Test (Dec 2016)

Atom could not open “1m lines” file and reported “crashed” after around 40 seconds.


](RAM Usage)

1 Like

Atom 1.14, which will be in beta soon, features many large file performance improvements. Here’s a few examples:

The last two PRs linked go into some detail about how performance was improved.


Awesome. Looking forward to it.

I think that the reason why some people are bothered by the relatively slow startup and why some people aren’t has to do with the editor paradigm that they’ve been brought up with.

  • Vi/Vim users tend to fire up the editor on-demand.

  • Emacs users tend to have the editor open all of the time.

There’s no right answer – it’s totally a user’s choice. Believe me, for 27 years or so, I’ve been quoted by this gentleman all over Usenet: Christian Lynbech quoting Petonic.

But, for those ex-vi users out there, you might want to investigate packages like remote-atom, remote-ftp, etc. Or, don’t.

That’s not to say, of course, that we wouldn’t welcome the improvements in speed :^)

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).

1 Like

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.

1 Like

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.

1 Like

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!

1 Like

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.