Why is Atom so slow?


#8

This is the most disappointing and WTF thing for me… I really don’t understand why Node.js and Webkit were chosen if they want to compete with a performant native text editor (Sublime) and bloated IDE’s (Eclipse).

When selecting a few paragraphs of text, the selection lags several lines behind my mouse! Scrolling is slow and switching between tabs is slow. And I mean slooowwww. On my machine (Thinkpad T440s), Eclipse is faster! Eclipse scrolls faster, switches tabs faster, selects text faster. And it has autocomplete. If Eclipse can outperform Atom at editing text files, then I think there’s a serious problem.


#9

That is really strange. The only slowness I ever see if when starting up. Is it that slow in --safe mode? Maybe some plugin is slowing you down.


#10

I just did a fresh install… no plugins beyond whatever is default and the Scala syntax plugin, although the performance was the same before I installed it. Same performance in --safe mode. Here’s a video comparison between Atom and Eclipse scrolling on my computer.


#11

I can barely tell the difference. Maybe it’s because of the video frame rate. But the only thing that matters is how it feels to you

It is comparing javascript to C/C++. I suspect it will not get any better in the near future. I guess parts of atom could be moved to a C++ plugin.


#12

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.


#13

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.


"Apps Using Significant Energy"
Atom is slow as compared to Sublime
#14

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.


#15

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


#16

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?


#17

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


#18

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.

Edit:
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?


#19

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.


#20

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.


#21

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…


#22

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

BTW, there is already an autocompletion feature.


#23

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


#24

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.


#25

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.


#26

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.


#27

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.