Why is Atom so slow?


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


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.


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.


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…


I think all you guys will be interested in this new PR which looks at improving startup performance:

@kevinsawicki is asking for a few more people to run a benchmark, in order to see what impact the changes he’s testing have on average.

Let’s help out! :smiley:


I’m vim user. I’ve recently tried emacs, sublime2, sublime3 and atom.

IMO, Atom is clear winner for ux and discover-ability except one important thing. It’s responsiveness is so slow.

  • starting atom
  • opening file
  • tab switching
  • mouse dragging(selection lagging behind cursor)

I’m using atom in linux. Do you all good in linux?

> inxi -v1
System:    Host: erty Kernel: 3.16.3-1-ck x86_64 (64 bit) Desktop: N/A Distro: Arch Linux
CPU:       Dual core AMD Athlon 64 X2 6000+ (-MCP-) speed/max: 1000/3000 MHz
Graphics:  Card: NVIDIA G84 [GeForce 8600 GT]
           Display Server: X.Org 1.16.1 driver: nvidia Resolution: 1280x1024@60.02hz
           GLX Renderer: GeForce 8600 GT/PCIe/SSE2 GLX Version: 3.3.0 NVIDIA 340.32
Drives:    HDD Total Size: 500.1GB (41.6% used)
Info:      Processes: 122 Uptime: 4:05 Memory: 2150.4/3950.8MB Client: Shell (fish) inxi: 2.2.12 


I’ve found --disable-accelerated-video-decode argument in htop.

Is that possible reason for slowness?

6830 /usr/share/atom/atom


No, that flag only affects hardware decoding of video files.


Unfortunately, I too, have stopped using Atom in favour of ST3 simply due to the perceived responsiveness of the application. I don’t have a lot of patience when I’m knee-deep in programming a new product feature to wait for files to open, delays in tab switching, etc. It’s not massive, but compared with ST3, it feels like the UI is running through molasses.

I love the extra functionality that Atom provides, I love the package management, the theming, the community… But I can’t use it as my main editor when I still get this little annoyance all the time.

For those that are interested, I’m running it on a MacBook Pro Retina 15’


I just had to give up using Atom as well because of the lag. Startup time has never bothered me. There’s a slight lag while typing that causes me to make mistakes, especially while in vim mode. The selection lag is very noticable and bothers me a lot.

I also love the features. Splits are great, the project navigator is great, the editor is beautiful, theming is great, plugins are great.

But I just can’t get over the lag.

On a Mid 2012 rMBP.


I totally agree with most of the comments on the top.

One of the most important details that is preventing me from moving to Atom full-time is its lag. It gets no where near Sublime Text 3 and that is quite damaging for my work flow.

At this point I think some optimisation should be considered a priority, at least until its working comfortably.


I’m an idiot noob, but since nobody has mentioned it here I want to just say that 1. recent updates seem to have improved the load time and general responsiveness quite a bit, and 2. somehow (and I might be wrong) it seems as if it actually works more smoothly when installed via choclatey? Just my $0.00002 or w/e


Just wanted to chime in here as well. Similar to most folks here I’ve been a Sublime Text user for years. Atom was initially very exciting. I have it configured exactly as I want it and everything about its UI, theming, plugin system, etc is fantastic… until I start using it for its primary purpose. Editing code. It is slow, dead slow. As mentioned elsewhere these common tasks suffer most (starting atom, opening file, tab switching, mouse dragging). They are noticeably laggy to the point of being annoying and disruptive to my workflow. I simply can’t get over it and despite really wanting to switch from Sublime to Atom I just can’t get myself to do it. I’ve tried on a number of occasions and always end up back in Sublime after a day or so using Atom. As someone else also mentioned, perhaps I’m just spoiled by the insane responsiveness of Sublime, but on the other hand no other code editing app I’ve used on the Mac is nearly as laggy as Atom, and I’ve tried quite a few. The general responsiveness of Atom needs to become a priority.