Why is Atom so slow?


One of the pinned topics on the front page of the board is:

which is pretty detailed … the simple version is at https://atom.io/roadmap.

You can find the general overview on this blog post here:


It is based on Node which is slower than C++ and it uses chromium as the display engine and that engine reflows the DOM which is slow. This slowness is well understood and is a trade-off for the excellent hackability of Atom.

I personally use notepad++ for text editing and Atom for program editing. The combination works really well.

Atom is not a simple text editor.

Coffeescript has nothing to do with slowness. It generates fast normal

That is your perception. I perceive it as a powerful sensible tool.

That wouldn’t be Atom. Atom was intentionally designed for all the advantages of node/chromium.

That is flat-out wrong. I can hack all the core code at run-time. That would be impossible with your suggestion,

This is also flat-out wrong. You can write packages in Javascript.


Sorry, I saw the API page but it didn’t have anything about performance in that post itself, so I didn’t dig further. Doing so now reveals this link about different startup time enhancements.

However, it appears those enhancements are all past tense, already in the release version. So we’re still looking at a slow text editor. In 2015 this is just deeply confusing to me. We have so much power under the hood, in the silicon, and any newly built text editor that is slow to open has fundamental design issues.

I just did some informal testing on startup times of Atom and its contemporaries. These are all warm/second launches: restart Windows, launch and close each app, then launch them again.

  • Atom 0.176.0: 5.1 sec

  • Microsoft Word 2013 64-bit: 4.0 sec

  • LibreOffice Writer 3.9 sec

  • Cream VIM 0.43: 2.1 sec (and that’s with a flash of an error along the way)

  • Sublime Text 2.0.2: <= 1 sec

  • Notepad++ 6.7.4 Je suis Charlie Edition: <= 1 sec

  • VIM 7.3.107: <= 1 sec

  • Light Table 0.7.2: 2.4 sec

Note that the time for Atom is actually somewhat generous. It’s the only the application where I see a spinning donut for some time after it’s opened/rendered. So it’s not quite ready at 5 seconds, though I’m not sure of the details of what it’s doing. I didn’t count the extra 3 or so seconds of spinning donut after opening.

From an engineering standpoint, a text editor is very similar to a word processor (BTW, what a terrible term for writing software – it’s amazing that it stuck, that we all say “word processor” all the time like it’s a Cuisinart for words, and that we don’t call Excel a number processor.) Text editors have lots of advantages compared to writing software. For one, they’re much lighter weight, don’t have to embed all sorts of objects, images, sophisticated grammar and spell checking, highly customizable tables, charts, shapes and colors, rich formatting options, dynamic tables of content, layouts, etc. – all the things that make modern writing software similar to what they used to call desktop publishing software. And Word is so freaking heavy because it has to be backward compatible with several generations of fundamentally different file formats from before the modern .docx XML framework, it writes PDFs and does a million other things that perhaps only Word maestros even know about.

Still, Word opens faster than Atom. Relatedly, I enjoyed reading about LibreOffice’s latest release and all the things that went into it. Michael Meeks has a nice post about it. Like MS, they’re burdened with a pretty heavy application that supports lots of file formats and has all the rich features of modern writing software, spreadsheets, presenters, etc. (For dev geeks, Caolan McNamara has a cool post about how they used Coverity to get down to near-zero bugs, and Michael Stahl at Redhat has posted about getting away from cygwin for build time improvements.)

Their architecture is different so their specific moves and decisions aren’t directly portable to Atom, although some of the things they’re talking about might be relevant at a certain level of analysis.

I think node.js is essentially brilliant, has made life better. But I don’t understand why anyone would build a desktop application out of it if they didn’t have to, especially if it’s going to be slow. It doesn’t seem like a node app would have to be slow, but I can’t find any details about the Atom architecture beyond the brief blog post, and I’m no node expert. Maybe node desktop apps are necessarily slow. It’s going to be very shoehorny whatever you do. Why would anyone invite the DOM into their desktop application? The DOM is the worst. It makes no sense to voluntarily use it for real software. Yes, we can do all kinds of things with web apps, and yes they’re much richer and faster than they were in 2008. But nothing else logically follows from that truth – they’re fast…er than themselves historically, not fast by normal desktop software standards.

It would be great if we could get something going to redesign the Atom core. If creaky old Notepad++ – which doesn’t leverage modern APIs, instruction sets, or acceleration at all – can open in a second or less, then a clean-sheet modern text editor like Atom should open in a tenth of a second. This is a very doable thing given modern operating systems, modern CPUs, modern GPUs, etc. Computers are incredibly fast now – there’s no reason for software to be slow. How hard would it be to build a modern desktop application core that runs in a flash, but presents the same plugin API, or even extends it? It doesn’t seem hard. It’s a text editor. An extensible text editor. I’m in for fifty bucks easy to build a new core. 2,000 x $50 is $100,000. I don’t think it should take more than that, but I could be wrong. It might not take any money. I would think Github staff could swing it.

But I’m happy to pay. We need a next-gen, fast editor from somebody – it might as well be Atom. Maybe UltraEdit is already there, but they don’t seem to have a plugin architecture, which is a nonstarter. Atom appears to be architecturally unsustainable – it can’t deliver the responsiveness that a lot of us take for granted, and that we should take for granted in a clean sheet desktop text editor. Sublime has checked out. Notepad++ has no future in its current form and very little plugin energy at this point (and is Windows only.) Brackets seems as slow as Atom from similar bizarre decisions, and more narrowly focused on webdev. It would save a lot of new effort if Atom asserted itself with a new, serious core.


Mark said: “That is flat-out wrong. I can hack all the core code at run-time. That would be impossible with your suggestion”

Okay, so we’re talking about “hacking” the core. Maybe I haven’t read enough of the docs, wherever they are, because I have no idea what we gain by being able to hack the core as opposed to writing a plugin or extension as normally understood. There are lots of degrees of freedom (in the non-statistical sense) in plugin APIs – I assume anything people wanted to do with plugins could be supported without needing people to be able to (easily) hack the “core”.

Mark said: “This is also flat-out wrong. You can write packages in Javascript.”

Great. (Well, not great, but better than just CoffeeScript.) The point would be to actually say that in the Create a Package page. It’s not there. I had done a Find in Page. The word Javascript never appears in the document at all. I think a lot of the de facto documentation might be hidden in the discussion threads, which is a rough road.

Anyway, I’m stumped on the architecture, on what it means to be able to hack the core and why that’s plus. Multithreaded plugin sandboxes seem more fun.


They don’t?

Because that’s the point really.

Really, it seems like you’re looking for something in the wrong place. Don’t get me wrong, if anyone would build what you’re proposing I’d be downloading it right this minute. I’d love to see something powerful and modern like that and it doesn’t seem like Sublime is going to provide.

But the point of Atom is to take JavaScript, the DOM, Chrome and Node and build on top of that. Because thousands of developers do that all day every day and this will enable them to create the tools they need. Also, you will be able to take Atom and stick into something else, build stuff on top of it.

You’re simply missing the entire reason d’être of this thing and proposing it adapts to your vision. Take a step back, read some more docs, check out the packages, then come back and see if you still disagree.


You just keep saying the same thing. We keep giving the same answers. To my ears, you are starting to sound trollish.


Note: This is an official warning.

Seek first to understand, then to be understood

Stephen R. Covey

I’m going to agree with @mark_hahn in that your posts appear to be trolls, @JoeArizona. You come here to post with angry complaints, all the while admitting that you haven’t read the documentation, the blog, or the forum; and then you do not read the responses. You are not engaging in a dialog, let alone a constructive discussion.

This is all I’ve seen from you so far @JoeArizona. I hope there is more you have to contribute.


In the eighties, it was “Eight Megabytes And Constantly Swapping”… I mean, there is this other editor, but also there is precedence for editors being a bit slow. It seems to work out well. Especially given that said editor is still going strong, after 30(!!) years.

So if Atom is like that, speed will not be an issue in the grand scheme of things. :smiley:


I would also like to lend my feedback to this thread. I’m not meaning this to be a venting of frustration, but just wanted to make sure that my experience was also reported.

I too am having incredible performance problems when using Atom. It takes about 5 seconds for the initial launch on my Ubuntu-distro machine. I had already attempted to disable the majority of the plugins to see if that would help issues, which unfortunately it did not. I then searched Google and found this thread.

I wish I could lend some development input, alas I am no developer. Just a simple user wanting to find a great go-to text editor.

You guys have obviously put a lot of work into this and are curious of user input, which is great. Perhaps you could offer a “lite” version which mainly focuses on what I believe most users want out of Atom. This could be a terrible idea, I don’t know. But I just thought I would throw it out there.

Thanks for all that you guys have done though!


You’re looking for an alternative and explained why/that some of the ones you listed are nonstarters. But you didn’t talk about VIM, even though you listed it. Maybe NeoVIM is for you? Starts as quickly as vim, and it’s going for a nice plugin architecture.


Let me try to give this a positive spin. I feel that the startup time of Atom is not too much of an issue because I usually open a whole project at once in it. (I “cd” to the root directory of my project, then I do “atom .” from the command line.) And from then on, I can just keep working in that instance of Atom that’s already running, and I don’t perceive much of a problem there. When I do cmd-t, for example, to open a file, I get real quick responses. (It sometimes has to parse my project, and I don’t understand when, but it does introduce a delay. Obviously, the delay depends on the project.)

Funny how they said that about Emacs, too… The argument still works, 20 years later.


Hi all, some thoughts:

Am I being too negative? Probably. I’m certainly being negative, complaining and so forth. The troll thing I have to disagree with, unless we’re sharply breaking from the established definition of “troll”. Sometimes people define it to encapsulate all criticism, negativity, or minority views, but I don’t think that’s the prevailing definition.

A lot of things about Atom were hazy to me until this week. I still feel like I’m flying blind, so many things I don’t understand. However, I’m going to stick to the position that this is largely due to a lack of documentation, and this claim seems uncontroversial.

I used to think Atom was something I’d eventually have to pay for. I saw this somewhere in 2014. I think it’s become FOSS along the way, but I’m not too sure about the details. Some of my reactions were probably framed by the implicit assumption that this was soon going to be a commercial product.

So on the performance, I think the situation is bigger than my quick data on startup times. People are talking about what happens when they have a few plugins and decent-sized files, and performance after startup. There are pervasive issues. I haven’t seriously exercised Atom. That’s partly why I’m alarmed. I see slow startup on a laptop that I just did a clean Windows 8.1 (64b) install on last week. The Sony VAIO bloatware in concert with the detritus of a year of heavy use and countless app installs was just dogging it down. A complete wipe and Win8.1 re-install did wonders. Everything is faster, and I hear the fan much less. Then there’s Atom. Atom is the exception to the spring-fresh feeling. The first startup after a reboot is somewhere around 10 sec.

I don’t know that anyone has actually answered my questions about the performance or the architecture. Did I miss this? Braver had a good answer about Atom’s niche and rationale. I think or Github staff had posted the link to some pages, but the performance enhancements are already in .75 or .76 according to those pages. From what I read, we already have the new, improved-performance 1.0 API. That’s surprising to me. I know I’m being critical, but I’m really confused about what’s happening at execution time, say on startup. Something just seems wrong, like maybe a bug, not even a design issue.

It’s taken me 48 hours to wrap my head around the fact that the DOM is here. The DOM is here? I know that’s implied by node, but I don’t think I knew about the leveraging of node before. I never expected to encounter the DOM in a text editor. It’s very confusing to me, like if you had told me that Atom is based on the TurboTax engine. They have no logical connection – the DOM has nothing to do with being a text editor.

The difference between a text editor and writing software is that the former produces output meant to be read by a machine and the latter produces output meant to read by humans. A text editor is for code and markup, not presentation. The DOM is on the other side of the glass – it’s part of a rendering engine, establishing the hierarchical and semantic structure of a document to be rendered for human readers. That’s only one level of analysis and there are lots of others you could use, and there are functions in DOM does that would be useful to a text editor, but it just seems strange to me to use the DOM. If it’s the reason Atom is so slow, even with the new API, then that’s a tragic decision.

It struck me that if you’re going to go DOM and js on this, it might make more sense to just go all the way and deploy it as a Chrome app. I’ve been toying with Codeanywhere, and I’m curious about Zed and ShiftEdit. At least two of them are built on Ace, which is apparently JS. They might perform better in Chrome than they would standalone. I have no idea, but if so, it might be true of Atom as well.

If you don’t want to do a hard pivot and build a modern native client app, you might want to look at simd.js to leverage some the power underneath you in the CPU: https://software.intel.com/en-us/articles/simd-javascript-faster-html5-apps

There are also specific CPU instructions now for parsing text strings, which can lead to major speedups: http://en.wikipedia.org/wiki/SSE4#SSE4.2

There is some C++ in Atom (not counting Node’s source), but I’m not clear on how it fits in or what it’s doing. If you have C++ code, you can inline the assembly for parsing strings. Or it might be accessible through simd.js – I’m not sure if and how SSE 4.2 is handled there. Google did some amazing things with Dart along these lines: https://www.dartlang.org/articles/simd/

I was wrong about UltraEdit. They have some kind of scripting and add-on support, but it’s not too deep. All of this discussion is framed by the fact that I need to make a longer term decision about which editor to use, instead of playing around with several. It’s inefficient. I just installed UE and it’s incredibly powerful, and much faster. I had hope for Atom, but it needs a major speedup. None of the editors are perfect – I’m just sticking to position that we have incredibly powerful hardware in all our machines now, and there are well-know ways to exploit it. Perhaps this fact is underexposed, and maybe front-end web developers don’t have any good reason to think about the hardware much. That’s fine, but the fact is it’s there, and it kills me to see slow text editors in 2015.


One definition of a troll is someone asking over and over for something impossible. Atom CANNOT be rewritten. Neither Node nor the DOM can be abandoned. It wouldn’t be Atom. Two years of work would be thrown in the trash can.

I think you are fitting that troll definition. Every single one of your suggestions is impossible.


I agree. I think the PRIMARY point of Atom is to build a text editor based on web standards, not necessarily to build the fastest editor to compete with Sublime or the others out there. Right now, that means Atom is going to be “slow” - point blank. It won’t go head to head with Sublime or VIM or any of the native editors for a while. Now, is it as fast Brackets? No, but that will improve in time. Also, in time, the performance of web standards-based applications will improve as the JS engines and DOM renderers get faster - probably by hooking into the various things JoeArizona talked about in his previous post.

However, I don’t think his question is trollish at all - and honestly its probably going to be one that is going to be asked over and over as more people find Atom. Until people understand what it actually, TRULY means when an application is written using web standards, they are going to expect the same performance they get from their other apps (see the complaints from the Facebook app when it was HTML5 based). I know i’ve had to defend Atom recently among some friends of mine who didn’t know what the point of the whole thing was.

Maybe a note somewhere on the website to brief newcomers on why its “slow”, or a sticky in the forums?


I can tell you are not in marketing. (grin)


I could create another sticky, though I think we have too many already. I also feel like if people find this topic, then they should find the post I made above that talks specifically about the tradeoffs you mention:

As for the website, that’s beyond my control since I’m not an employee of GitHub.


And the thing is… What is the people discussing here? The start time? Really?

For me Atom is quite performant once it’s open.
It takes 5 seconds to start so I’m loosing 0.0001% in productivity of my next 8h of work, guys, we have to rewrite the editor.
Don’t you see something wrong in all this discussion? I could understand it’s beginnings which I never experienced. But I think now this is a out of place. Is still the people complaining about the performance while working?

If anyone is wondering for my system I’m using a HP laptop running Ubuntu 14.04, 4 Gb RAM AMD A8-4555M.


The reason why I consider JoeArizona’s posts to appear trollish isn’t because they are negative, it is because it seems from the content of the posts that they aren’t spending any time reading what other people have to say … even in direct response to their own posts.

I very much agree with Jeff Atwood’s ideas on how to build better forum communities:

There are plenty of negative patterns on forums that are not intended to be trolls, but are in actuality because they negatively impact the spirit of the forum. This topic has been open for six months and has had plenty of negative posts on it. And I’m certain it will continue to accumulate them. But disagreement isn’t trolling necessarily, disrespect is.

To address some of the points made above for others who read this topic:

  • Licensing and Cost are covered as the very first items in the FAQ: Have a Question for the Atom Team? Atom is Open Source and free as in beer.
  • Yes, Atom is slower than other editors. See the rest of this long topic for discussions of why that is and why some people don’t think that’s a huge problem.
  • Regarding Atom’s overall architecture, see the Atom blog post The Nucleus of Atom
    • “… it might make more sense to just go all the way and deploy it as a Chrome app …” Yep, it is already based on Chromium. The reason why it isn’t a completely in-browser application is addressed also in The Nucleus of Atom blog post:

    the browser severely restricts access to the local system for security reasons, and for us, a text editor that couldn’t write files or run local subprocesses was a non-starter.


I tend to agree, though I understand that I’m perhaps less sensitive to speed concerns. I have two machines that I run Atom on:

  1. A brand-new Retina iMac Quad Core 4GHz Intel Core i7 with 32GB of RAM and a 512GB SSD
  2. A four-year-old 13-inch MacBook Pro Dual Core 2.3GHz Intel Core i5 with 8GB of RAM and a 320GB 5400rpm HD

Atom performs almost identically once it has started up on both machines, both configured the exact same. Startup time for me is:

  1. iMac — ~1.5sec
  2. MacBook Pro — ~5-7sec

And I invariably work on much larger projects on my MacBook Pro since that’s my work machine. So yeah, for me the only difference is startup time and I’m obviously not too bothered with that.


I also just noticed this Pull Request:

which may have a significant impact on startup times for people running HDD instead of SSD, who seem to be disproportionately impacted by startup time issues.