Why is Atom so slow?

Here’s how you do it: take advantage of this wonderful issue tracker GitHub has, specifically made for Atom. Believe it or not, people do actually pay attention to it. Just make sure that you can provide specific examples of areas where it gets really bad.

Speed doesn’t bother me as much as most people, but that’s mainly because I have never had a truly fast laptop for any extended length of time. I first learned to program in Java (confusing, ugly language) using Eclipse (extremely slow, heavy IDE) on a 10-inch netbook with a whopping single Intel Atom core. Talk about slow.

Also, at around the same time, my leadership position in a school organization at the time (this was only 1-2 years ago) had me using a Windows XP computer regularly, which usually took 20-30 minutes to fully boot and another 5-10 minutes to log in, slow for even those standards. Atom actually feels faster than some things, and as I’m typing this, I’m using a 5-year-old Dell Inspiron, my primary computer. Nothing like having to, on occasion, xkill Chrome or Firefox because it hangs. I even remember, one time, having to xkill a stupid terminal window.

(I do suspect a perf regression happened in the rendering side in the last month, though, but I have been focused elsewhere, so I couldn’t get enough info to troubleshoot.)

@impinball Are you refering to the 26 currently open performance related issues on Github (dating back as far as last year)?

I thought one reason of feeling Brackets start faster is that: Brackets start up with these orders to show: show window -> show menu bar-> show editor view in separate times.
But Atom show window、menu bar、editor view in the same time.
Maybe Atom could improve this user experience, @kevinsawicki

I hacked atom and improve atom start user experience, see https://github.com/atom/atom/pull/4269
you can have a simple test by edit: /Applications/Atom.app/Contents/Resources/app/src/atom.js

Hope you can test my patch and vote for the pull request.

I record a screen video to show what I mean.
Before modify: https://drive.google.com/file/d/0B8i7zRr2bfCATG8wNDJmR3ZQb3c/view?usp=sharing
After modify: https://drive.google.com/file/d/0B8i7zRr2bfCAbG5sYnBiUG53LXc/view?usp=sharing
Combine both: https://drive.google.com/file/d/0B8i7zRr2bfCAaFBQbkxfT0JleG8/view?usp=sharing
Please notice the window show time with the dock animation down time and the editor view show time.
before modify: window show at 00:02, the editor view show at 00:02
after mofify: window show at 00:01, the editor view show at 00:02
Same start time, same editor view show time, different window show time, but make user feels quick and better.

I’ve publish a hack solution to make the atom start faster:
see https://github.com/atom/atom/issues/4293

1 Like

I must say Atom’s startup time got much better lately. Great job!

I was a little disappointed with Atom back in the day when I created this thread beacuse it was advertisied like it’s the new great editor, comparable to Sublime Text (I didn’t use ST much but I remember it was very fast) and yet had such poor performance. Now I use Atom on daily basis on both Linux and Windows and I really like it!


The fun of use atom is to hack and learn.
Use open source and contribute to it :smile:

Updated, Also add a gist about the hack code: https://gist.github.com/yongkangchen/86f0284291584d0b7c78

It is convenient to use something like “emacs --daemon”?

that few ms, adds up, and on non-ssd it takes longer.

Here is something that works on speeding atom up for me:

That’s exactly how I felt. Everything else is great but the lag in typing and UI response killed it for me :persevere:

For this decade, I’ll probably stick with Emacs :stuck_out_tongue_winking_eye:

My primary machine is the latest Macbook.

Updated: http://blog.atom.io/2014/07/02/moving-atom-to-react.html
They have it before!

ReactJS VirtualDOM in Atom? (http://facebook.github.io/react/) or Integrate VirtualDOM in Atom (https://github.com/Matt-Esch/virtual-dom)

The fact that Atom is slow due to HTML DOM and CSS we all know, you guys should consider using or leverage with ReactJS VirtualDOM and do away LESS by fully utilize Javascript for styling and lot of perfomant…

Years ago, I’ve abandon Adobe Flex in Eclipse when it just hang with 1000 lines of code.

I’ve never miss Flash once ReactJS make it painless and so much clever tricks than JQuery.

@alitavector tom is already using React for the Editor. I can’t find the reference right now, but the dev team didn’t see significant speed benefits from it. They saw some promising results at first, but after converting more and more of the editor components, the benefit became less noticeable.

See this comment from @nathansobo about why they have chosen to move away from React in the future:

Edit: Found the reference about the lack of performance benefit of using React:

Are there any updates on plans to make Atom perform at normal client software speeds? I’ve had the same experiences noted above. It takes an absurd amount of time to open on a Windows 8.1 64-bit Ivy Bridge Core i5 laptop with 8 GB of RAM. That’s not awesome hardware, but it’s plenty powerful enough to run a text editor snappily.

I had no idea it was built with CoffeeScript until last week. I had a hard time believing, or even understanding, the claim when I first heard it. To wit, are there any architecture docs? In particular, I was looking for some kind of overview doc, something that said “Atom is made of this and this, and built like this, and here’s a diagram of the core architecture and API.” It must be there somewhere – I’m probably missing it based on labeling or something.

When I read the “Creating a package” page, I was thrown because it never says what language packages are written in, which is crucial. I missed the .coffee file extensions that appear here and there, so maybe people are expected to infer that the logic would have to be written in CoffeeScript. It would help so much to say in the introductory paragraph: “Atom packages must be built in CoffeeScript.” and then proceed with the rest.

When I searched on “Atom editor slow” I found Loren Segal’s detailed post. I’m so disappointed that this opportunity was seemingly blown. Sublime is AWOL right now – no one knows what those people are doing anymore, if we’ll ever see any activity from them again, or why they think they can charge $70 for a beta that hasn’t been updated in over a year and has no apparent future. Atom was coming in at the right time. It’s a brand new, clean-sheet desktop text editor – how could it be slow? A 21st century text editor needs to be fast. We’ve definitely entered the era when something as simple as a text editor should be instant. Atom doesn’t seem to be using anything the OS is giving it, or what Intel is giving it, whether on Windows, Linux, or Mac. To make a desktop application based on node and Coffescript is an incredibly strange thing to do – it’s deciding in advance to not be fast, to not be a robust desktop application. Liking a language has nothing to do with whether you should build desktop applications with it. There’s too much of a trendy vibe and not enough engineering seriousness. Who’s in charge of the core work right now? Can we hire some people to fix it? The core needs to be in a serious performant language, like modern C or C++ that actually leverages all the things a modern OS gives it for speed and stability. Even Go would be a huge advance. A properly engineered core would be arbitrarily extensible with Javascript or CoffeeScript, and better yet, Python, Ruby, Julia, Dart, or even any LLVM IR. It’s extensibility could be extensible. It could be as hackable as you wanted it to be.

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.

1 Like

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.