Why is Atom so slow?


#101

Some people report this behavior with the spell-check package. You may want to disable it and see if that helps.


#102

Just to clarify for those in a similar situation.

There is no need to start Atom in the safe mode. However, once it has started run ‘top’ and look for the hog Atom process and ‘kill -9’ it.


#103

I tried disabling the spell-check package and it did not change the behaviour. But for now I will keep it disabled anyway. Thanks for the suggestion.


#104

Actually, the right thing to do is to:

  1. Capture a CPU profile using the Developer Tools (tutorial on this coming soon to the documentation)
  2. Post the profile to the Issue that applies with as much information as you can
  3. Help us find the issue and correct it

Just killing the process doesn’t help resolve the issue, it just mitigates the symptoms.


#105

I’m using Sublime Text and had the intent to switch to Atom, but when coding gets intense with over 20 files opened and having > 2000 lines of code, Atom starts lagging and sometimes even stops responding. I’m not even running anything - just editing texts. Have to switch back to Sublime for heavy duty coding.

Does anyone know what causes the lag? Can Atom not handle long texts?


#106

Well, large files have historically troubled Atom since inception. Recently they changed from a line-by-line rendering, to tiles, which has improved performance massively, even with large minified files.
However we still get reports from some people seeing what you are seeing.
So there’s still some work to do it seems.


#107

@batjko I’ve read some articles stating that Atom’s usage of DOM to render text is inherently slow since the DOM is simply to massive.
What’s the source of the lag do you know? Is it from reparsing text into DOM or it’s simply because the DOM is too big that even without reparsing, it still lags?


#108

I’m not deep enough into it, but it won’t be a single thing that drags Atom on those occasions.
The core team have implemented many small and some pretty major rewrites of how Atom was rendering its views.

This recent blog post goes into some detail for what they have done just in the last month or two:


#109

While the may be some inherent disadvantages to using a browser, Atom is nowhere near close to hitting any wall in performance. There are a ton of opportunities waiting to be milked. I’m at codeconf and I had the opportunity to talk to several core team members who were very convincing in this regard.

One could ask why they don’t make these thing more transparent and tell the things in progress and ideas. @leedohm did ask @nathansobo about this transparency and he promised to do something. Even though he and the other team members are super-busy, they may have time to fulfill this promise.

BTW, I also talked to Elliot Sprehn from Google who is on the chrome rendering team and he promised Google was going to continue to speed up things, presumably forever. He mentioned being able to call directly into the rendering engine instead of going through the DOM, which was a nice surprise. I think he also talked about this in his presentation.


#110

And in five years or so… Atom runs on Javascript bytecode and beats the whole lot of them.


#111

I don’t know exactly when, but in the latest releases, besides the better performance at startup and handling huge files, Atom itself appears freezing more frequently. At first it was only handling huge files but now it freezes when I open settings, or view and apply updates in packages, navigate between tabs, and even when I only return to Atom (Alt + Tab). Of course, I use much more packages today, and still have to check if one of them is the reason (which I guess).

Even so, then Atom’s hackability, open source model, and strong community, gives me confidence of its evolution.


#112

Once an Atom window starts, the app is snappy. Not noticeably slower than Sublime, maybe faster. (Using Atom v1.0.0)

The problem however isn’t starting the app. It’s initialising windows. As part of my work I often open projects that come up sporadically. There’s a main group of projects I have permanently in a single full-screen window, but there’s hundreds of associated projects I may need to interact with. I navigate to the git repo on disk, run “subl .” and I’m there. Without skipping a beat I go from the shell to a loaded Sublime, pick a file from the sidebar and start coding.

When running “atom .” there’s a good few seconds just to be greeted with a disappointing empty grey canvas. Then some more waiting to see the file tree load. All in all a good 10 seconds to get from the terminal to having selected a file in the tree and start coding.

These aren’t big projects, either. It’s the same for a folder holding nothing but a single file. The slow start is significant and creates a disconnect. It’s no longer responsive. You’re sitting there thinking about stuff. I feel strongly compelled to go back to Sublime. At least for the majority of work where I need context-switching this delay just kills me.


#113

Really? It’s more like 2 here. But I will agree that Sublime has the edge, being almost instantaneous. I use Sublime for peeking into single files, quickly address something and leave it behind. For the main projects I work on most of the week though, Atom has it completely beat feature wise and the 2 seconds aren’t even enough to go grab coffee.


#114

In my case the lag during working with atom, was caused by a plugin. It would be nice to have a tool to hunt down CPU eating plugins.


#115

There is! And it is built-in to Atom and documented in the Debugging document that I’m referring to all the time :grinning:

https://atom.io/docs/latest/hacking-atom-debugging#diagnose-performance-problems-with-the-dev-tools-cpu-profiler


#116

@rrd108 Which plugin was it? I am trying to hunt down a plugin which is causing horrible lag too.


#117

I saw that php eats a lot of cpu. phplinter package calls php directly, so i disabled it, at it was the guilty.


#118

Not using Brackets, but comparing to Sublime Text, MSVC and MSCode (the interesting comparison), I would note that Webkit rendering latency is a big problem with Atom on Windows. Adds up especially for high DPI results. Idle redraw scheduling causes the rendering to cease until a rather lengthy set of operations is complete, for example, arrow key-repeat, or undo key-repeat. This is probably a spiral-of-death resulting from slow render times.

For whatever reason this is not a problem with the Webkit rendering in MSCode. (Changes to the event loop? Faster rendering?) And both Sublime Text and MSVC (duh) renderers are highly tuned for their targets; typically very little latency unless some lengthy task is blocking the scheduling thread.

Aside from that there are also some algorithmic problems to address in time, such as poor handling of very long lines.

Hope this will help guide some discussion.

EDIT: Did some package debugging. Eliminated culprits that were stopping the world for error reporting. Big improvement! Still issues but much more usable.


#119

Out of curiosity, which packages were that?

I think when people find such definite resource hogs, it would a good idea to open issues on the relevant packages’ repositories so their maintainers can be made aware (they often aren’t) and potentially do something about it.


#120

Yes, I think it’s not just a good idea (like a bonus), but actually vital to the overall status of the editor in the medium to long term, that performance issues are opened in addition to feature/bug related issues for offending packages.

I may be wrong, but I don’t know that there is much performance related feedback right now on package repositories. Either way I think more should definitely be encouraged :sunglasses: