I'm currently sitting at my Macbook Air 2013 writing this, which supposedly has a Haswell i7 ultramobile inside. According to my standards that's a pretty decent amount of computing power.
If you want to read a different kind of review on Atom please take a look at the Dylan foundry, since I'll be focussing a bit on the performance aspect of the editor.
A few words of praise
Before I dive in too deep, I want to bring in a few words of praise. Github has managed to create a huge buzz around their editor even before it got launched. At the time of this writing it has 23.2k followers on Twitter with only 4 tweets so far. Everyone is hyped by the editor. Getting traction on an editor is actually a big factor to its' success. Yzis for example died a slow, silent, and painful death.
Starting it you get greeted by a nice dark theme, with a info markdown - I love dark editor themes -. When you open the preferences you get a nice package editor and theme downloader.
The first thing I tried was using the fuzzy completer on a fairly big c++ project, and it was a truly pleasant experience. In fact if you don't use the c extension to ctrlp it'll be much faster than ctrlp in vim.
One of the biggest fears I had already start bothering me. I don't like the font rendering in browsers for text editing, this I guess is subjective.
You can modify the font size by going to
Atom->Open Your Config
Furthermore you can disable Antialiasing in the editor by simply setting
-webkit-font-smoothing: none; in your stylesheet. But good luck using bitmap fonts in Chrome.
So far, so good.
A good way to get an idea of what happens behind the scenes is playing around with bigger files. If you open a file that is above 2 megabytes big Atom throws you into the debug console saying that > 2mb files are not yet supported. What about something smaller ones?
By the way,
I have "reduced"(hah) my vim config to about 50 plugins, so it takes ~25 megabytes of ram
13248 /usr/bin/python /Users/dude/.vim/bundle/YouCompleteMe/python/ycm/server/ycmd.py --port=61028 --options_file=/var/folders/gp/6p30hs7x04356bh95mtf_34m0000gn/T/tmpYTYJAH 24848 /Applications/MacVim.app/Contents/MacOS/vim buildlog.txt
25m for vim and 13m for my autocompletion daemon(which I should probably disable on text files).
Compare that to same file opened in Atom.
42464 /Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --eval require('/Applications/Atom.app/Contents/Resources/app/node_modules/coffee-scr 77120 /Applications/Atom.app/Contents/MacOS/Atom 83584 /Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --type=renderer --disable-accelerated-compositing --js-flags=--harmony_collections --
Atom is the base application. Atom Helper are as far as I remember the Chromium embedded bridge.
Search speed and memory
Doing regex searches in vim on that file is instant. The memory barely moves.
24940 /Applications/MacVim.app/Contents/MacOS/vim buildlog.txt
What about Atom?
Searching for the character d takes almost 10 seconds in Atom, and significantly increases memory usage.
309404 /Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --type=renderer --disable-accelerated-compositing --js-flags=--harmony_collections --
When I say significantly, I'm talking 200 megs. I'm guessing that can probably be reduced a bit by disabling search highlights. Longer searches are not as slow, but unless you copy and paste your search term you might have a 20 to 30 second delay before you actually get to search what you want.
530268 /Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --type=renderer --disable-accelerated-compositing --js-flags=--harmony_collections --
A couple minutes later it actually got garbage collected a little, but I don't know how predictable this behavior is, waiting another 20 minutes yields following.
220196 /Applications/Atom.app/Contents/Frameworks/Atom Helper.app/Contents/MacOS/Atom Helper --type=renderer --disable-accelerated-compositing --js-flags=--harmony_collections --
Either way, in a file as little as half a megabyte without syntax highlighting you'll get choppy scrolling performance on a Haswell machine.
Let's take a look at Textmate 2:
121160 /Applications/TextMate.app/Contents/MacOS/TextMate -disableSessionRestore 0
Compared to Atom the search is blazing fast, and the memory usage increases by 17 megs when you use the search window, and immediately decreases again when you close it.
To be fair, Textmate 2 does not highlight all matches in the Editor so it's not a fair comparison. Either way, search performance wise it beats Atom by far, why? Because it's not a frikkin web browser pretending to be an editor. Sorry, I lost it for a second... please let me continue(disclaimer I don't use Textmate or Textmate 2 for that matter, I just like to fiddle with editors every now and then)
A little caveat, it terms of accessibility of starting to build extensions Atom definitely seems to be somewhere near the top of the list.
Why big files?
So, you're reading this, and you're thinking, lol you're so biased, I never open big files in my node project. While that's true, big files give you a good idea of what's happening under the hood. People actually spend a lot of time thinking about how you can build efficient syntax highlighters.
Why is it so slow anyway?
Overhead. Take a look at this, the dom of a three liner of text in Atom:
<div class="lines" style= "height: 54px; min-width: 913px; padding-top: 0px; padding-bottom: 0px; top: 0px;"> <div class="line"> <span class="null-grammar text plain">GNU GENERAL PUBLIC LICENSE</span> </div> <div class="line"> <span class="text plain null-grammar">hello</span> </div> <div class="line"> <span class="text plain null-grammar">what's up</span> </div> </div> <div class="underlayer" style="height: 54px; min-width: 913px; top: 0px;"> <input class="hidden-input" style="top: 0px; left: 0px;" /> <div class="selection" callattachhooks="true"> <div class="region" style="top: 18px; left: 72px; height: 18px; width: 48px;"> </div> </div> <div callattachhooks="true"> <div class="bracket-matcher" style="display: none"></div> <div class="bracket-matcher" style="display: none"></div> </div> <div class="spell-check" callattachhooks="true"></div> <div class="wrap-guide" callattachhooks="true" style= "left: 640px; display: block;"></div> </div>
Everything is html. While other people are thinking about how they can optimize their data stores so that highlighting doesn't take more than a byte, you have a dom element per line. Can you optimize this? Sure, but wouldn't that break the ease of extensibility, and use the chrome debugger to debug your extension promise? Quite likely.
Delaying search so that not every character triggers the search, would improve search behavior. Maybe though this would be inconvenient for small files. In that case this option should trigger automatically for files of a certain size.
Make fonts configurable somewhere in the preferences. The stylesheet is nice, changes in the stylesheet get applied instantly, but programming font is such a basic element of code editors that it's one of the first things people touch.
Atomic undo. This is a big one. Most editors do it, and most people don't even know what it is. I'm guessing this might be in the works already, but I wouldn't know either way.
I think that Atom is really just the first step in a different direction. Will I use it? Unlikely. But that's not the question.
If you had a Chromebook this might very well be the best editor backend there is(well, next to ssh'ing to your emacs/vim machine). But it's CEF isn't it? That's kinda native, and won't run on ChromeOS right? "Kinda" native, is the key.
I'm pretty certain that the performance had been much worse had I not opened a text file, but instead a big source code file. To be fair the only ones I've seen creating 500k source code files were Microsoft.
But until someone comes along with a well designed embeddable text store backend I'll keep using my crappy vim in tmux.
What about you though? Will Atom be successful?
It depends on your definition of successful. I'll guarantee you that it'll gain traction, and will become quite popular.
Will I switch to it? Still unlikely.
Ps. for all you guys worried about Atom phoning home. Install Little Snitch, use your hosts file, or try pf. I'm not sure if I can consider that valid criticism.