Why is Atom so slow?

Watch the part where I’m selecting slowly around the :04 mark. Can you see where my mouse is? The selection gets to be literally 15 lines behind my mouse. When you’re quickly trying to make a selection with any sort of precision, it matters. When eclipse is better at this than a text editor, it hurts.

In my opinion, they didn’t intend to compete directly with either. The major benefits to Atom, in my eyes, are:

  • You can theme and style it using CSS/LESS
    • Experts already exist
    • Animations are possible without having to create a special API
  • You can extend it by writing packages using CoffeeScript/JavaScript
    • Experts already exist
    • Very low barrier to entry
    • Testing frameworks already exist to help people write high-quality extensions
  • Large bodies of libraries already exist in the form of npm packages
    • This gives both Atom and extension writers a big boost in productivity
    • Growing all the time … and probably faster than non-extension libraries of code for other editors
  • Integrated Debugging tools
  • And more I’m sure …

Now, certainly … if performance is of supreme importance or the above benefits aren’t useful to you, I can completely understand someone else making different choices. Personally, I find the above very compelling and I believe that, in the long run, the performance issues can be addressed through optimization and the judicious replacement of JavaScript with native C/C++ libraries.

Disclaimer: I am not an employee of GitHub nor a member of the Atom team. I’m just a volunteer.


All of this makes me want to love it, but it’s not just about performance being of supreme importance… it’s about performance being at a reasonable level rather than being sluggish and creating an overall frustrating experience. When scrolling slowly on a page with under 200 lines of code the selection should not lag.

And I don’t know about the “official” stance on the editor, but everyone is trying to sell it as a Sublime replacement. And the extension system does seem far superior to Sublime’s. But the editor just isn’t usable to me right now.

I hope this has more to do with the Linux version or my system than Atom’s architecture in general.


To that extent I can agree.
There’s a lot to love about Atom, and while performance issues (certainly the slow launch) are both excusable and tolerable for many of us, they are less so for many others; and they undoubtedly affect the overall user experience negatively to those using it heavily at the moment (which I am not, strangely, but I’m empathetic).

Atom for Windows is also very slow. I’ve got a brand new laptop and my Visual Studio boots up even faster then atom.
Is there a known cause for this bad performance? Is someone looking in to this?

1 Like

Let’s try and keep the topic constructive rather than just venting frustrations.


On that note, I would like to know what knowledgeable people think would make Atom more scalable - both in terms of responsiveness of large buffer sizes, and app launch and load times, which appear to be the two major performance gripes people report.

Beyond the good practice for individual package developers, I mean.
With the current high-level design, is it possible to reach Sublime or even Notepad+±level performance by any chance?
And if not, what might possibly get us there?

I doubt it could be done without losing some of the extensibility advantages.

I keep notepad++ around for non-programming. It loads so fast that it doesn’t bother me to fire it up for large files or quick text file editing. I am convinced the feature set of Atom will grow exponentially and I am already confident I will be using it for years.

P.S. What is weird is that ST2 also took four seconds to load for me. I must have had a bad plugin or something.

1 Like

This doesn’t help you, but I just tried the select lines thing on OS/X and it kept pace with the cursor. So, it’s possible for performance to be good, but the Windows version is lagging the OS/X version.

Hmmm this is interesting… so there is hope after all, perhaps it’s an issue with our specific platforms.

I get the same horrible selection lag whether I’m on my undervolted Thinkpad laptop, or my powerful gaming PC. For comparison, I tried out Brackets and it has similar selection lag but not as pronounced… the selection on Brackets lags maybe only half as far. I worry about whether this lag will get worse when we do eventually see features like autocompletion and code inspection and the editor has to do extra work on search and indexing…

Hopefully this will be offset by software improvements and of course hardware speedups.

BTW, there is already an autocompletion feature.

Hi guys…I did a suggestion here, I wish to know about a technical opinion if is it possible

personally I found atom much more faster and less laggy than the bracket editor but the startup time is killing me, practically I chose to keep the editor minimized all day for small scripts editing

1 Like

Keeping atom running as a background app to improve start up performance is something worth looking into. There could be a few other ticks to help improve performance such as defer loading of certain packages.

All packages have the option of delaying activation. Generally, loading a package should take much less time than activating it. And even then, packages have techniques available to them for delaying the expensive parts until they’re actually used. See the Best Practices FAQ for more details.

I think one part of the startup time issue is due to NPM dependencies management. NPM allow each package to have its own dependencies with a specific version. That’s a nice feature for app stability but it’s a disaster for startup time in bigger apps.

As a result of NPM dependencies management, the default version of atom contains:

  • 11 copies of temp
  • 9 copies of underscore
  • 8 copies of async

I tried to use the npm-dedupe command, but unfortunately it cannot de-duplicate if a single package is using a different version from the others.

It might be worth trying to build a npm-dedupe that de-duplicate as much as possible by grouping package by versions, I’m not familiar enough with NPM to say if it’s feasible.

1 Like

Some deduping happens during the build process already, but I can see how different versions can put a stop to that.

I am generally in favor of, eh… encouraging… package developers to keep up with core-supported versions of node and other dependencies, at least within a reasonable amount of time. It’s industry practice and would save a lot of hassle like this.

1 Like

What part of dependency management takes so much time? Do you have measurements to show that this is a problem area in Atom specifically? I’d rather not sacrifice the stability if it isn’t a noticeable chunk of startup time.

It’s not the dependency management itself that takes time, it’s a consequence of the way it’s done. If atom uses 9 copies/versions of underscore, that means node has to load underscore.js (which is 45KB) 9 times from disk, and interpret/optimize it 9 times.

I have no measurement, because I would need to a deduped version to measure the difference, so it’s more a wild guess. The problem is not specific to atom, it’s something all node apps have, the difference is that most node apps are smaller than atom and don’t really need to start quickly.

That would only take a few ms, at most.

When Atom is already running, and I do cd /some/where and then atom ., it takes quite a bit of time for it to come up. During that time it actually opens another instance of itself, only to shut it down again. It looks as if creating the instance takes a long time. I wonder if it is possible to shortcut this somehow…