Why is Atom so slow?


#165

User since inception of Brackets here.

In my experience, Brackets is usually much slower than Atom when it comes to open minified files or big files.

To note, Brackets on Windows is orders of magnitude slower than the OS X version of it. (At least, this was the situation when I have switched to OS X one year ago).

Talking about the time they take to “boot”, Brackets it’s much faster in showing you something (a white window), but then it takes some time to load the whole UI, especially if you have plugins.

Atom takes longer to show you the window, but once it’s opened, the UI is loaded in few seconds.


#166

Did you complete all the compling?


#167

We have this benchmark suite:

For some things, ES6+ is worse than ES5, for some things it is better. It seems for the things that we use, it is better. Feel free to add to it.

The main benefit for us though was the ease of profiling and debugging the actual source code, as there is no compiled code when used natively. It helped us identify things we could do a lot better. TaskGroup v5 became a lot faster, a little bit from the specific conversion, but mostly from the insights the profiling and memory stuff we did. I know that is a bit of a cop out answer, however we tried to gain such insights with compiled code, and it wasn’t as fruitful.


#168

One way we could really improve Atom is to run a server for the Node filesystem access stuff, and any other functions that are useful across all instances of Atom. This way, Atom will load just the UI when we open a new window, then it will simply send commands to the already-loaded server.

Is anything like this already in place?

I also think Atom could benefit from some UI re-architecting (not necessarily changing the classes and functionality, just changing the underlying rendering techniques using requestAnimationFrame and transforms for performance, and also decoupling data from UI rendering, as right now synchronous functions from plugins really slow things down more than ideal).


#169

I have 3 different computers that I use for various things. My main rig is a windows 10 machine with an amd fx9590 and 32 gigs of ram. When i run Atom on this machine its hangs so hard that it almost crashes my machine. I’ve tried completely removing all of my plugins and even doing a completely fresh install of windows 10 but the performance is so bad that I simply cant use the editor. I love atom on my Linux box and I even don’t mind the slightly slower performance i get on my windows 7 laptop but on windows 10 its completely dreadful. Its a bit weird because my Linux computer is a 10 year old laptop and my windows 7 laptop is a 4 year old laptop yet they out preform my hand built gaming desktop when it comes to atom. I have no issues with Node or NPM but when i try to use APM it crashes my power shell/cmd. Even with v1.8.0 of atom (there were marginal improvements) its like watching a power point presentation which is extremely sad because I really like the workflow on atom vs sublime, brackets or lighttable; all of which work perfectly fine. (I use it some times for clojure development). Guess I’m staying with Emacs until the tech catches up. Its really frustrating because while i love Emacs for many things, I like the idea of atom more.

Oh btw, when i look at the process for Atom, i see 4 different atom processes in my task manager and it tends to spawn infinite node processes every now and then.

just a side note: why did they choose to write this thing in coffeescript…


#170

This is not typical. I have a much crappier computer (laptop, 8 gigs of RAM, Intel i7) and the two Atom windows I have open (and have for hours) aren’t even taking up 600 megs or more than 0.5% CPU.


#171

The four Atom processes are normal as Atom runs on Chrome, which does something very similar. I know you said you removed all of your plugins, but could you try running Atom in safe mode anyway (atom --safe) and see if that helps things?

Alternatively try starting Atom with atom --disable-gpu.


#172

I’d like to give the Atom engineers a snippet to work with to test speeds.

I’ve documented repro steps here: https://gist.github.com/kevinSuttle/9830ae60aa67f584439d53d5162e88d2


#173

The editor is fast on the main machine.

When I am running the editor in the VM (Linux Ubuntu 14.04, Windows 10) it is much slower. The performance impact is much higher in the VM than for other applications. Someone else is running it on Ubuntu 16 LTS and has the same issue.

Since I develop in the VM, I am impacted by this all the time.

The impact I am most concerned about is the delayed feedback between pressing the keystroke and seeing it echoed in the editor. If there is a reduced responsiveness to other actions, it is not noticeable for me.

My hardware is serious enough that even VM shall work well for most of the tasks: Intex Xeon CPU, E5-1620 v3 @3.5GHz with 32 GB of RAM. I am running latest VMWare on Windows 10 host.


#174

What resources are you giving to the VM? It doesn’t matter what the host machine’s specs are if you’re giving the VM 1GB of RAM and a single processor.


#175

Linux VM has 4 GB
4 processors

windows 10 VM needs less in its case:
2.2 GB RAM
2 processors


#176

I dont know if this idea was even taken under consideration.
Would Go as a backend be a better solution than JS code everywhere?
Electron with react sounds like a great UI renderer but i believe Go would make a lot of parts much more efficient/performant with websocket connection between the two.


#177

I think Atom boots slower than my Windows system. Maybe I’m using it wrong, I don’t know. I usually open small files and close them after under a minute. Perhaps it works great if you open a project and never close it, but for things like this it’s pretty much unusable. Sorry, I don’t want to buy an SSD for Atom. Goodbye!


#178

If you have an Atom window open in the background, it won’t have to load all of its packages every time you pop open a new file.


#179

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.


#180

@hugollm how would we go about testing those assumptions?


#182

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


#183

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.


#184

[

](RAM Usage)


#185

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.