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 Link to heading
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.
But wait Link to heading
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?
528K openwns/buildlog.txtBy the way,
Javascript is not made for string manipulation
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.txt25m 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 Link to heading
Doing regex searches in vim on that file is instant. The memory barely moves.
24940 /Applications/MacVim.app/Contents/MacOS/vim buildlog.txtWhat 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.
As a little bonus you can trigger fast subsequent searches, scroll around a bit, and increase a single editor windows memory usage to multiple gigabytes in size. I’m guessing this is in part related to how string processing in javascript works, and in part related to how their highlighting code works.
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 0Compared 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? Link to heading
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? Link to heading
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.
Suggestion Link to heading
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.
Atom’s future? Link to heading
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.
Conclusion Link to heading
Atom definitely looks like a pretty editor, and the fact that you can use coffeescript and javascript instead of ruby and python to write extensions is definitely interesting to some people, to others not so much.
There have been discussions about using ropes as a backend for mutable strings in node I think. A long long time ago anyway. But it’s not that easy. All the string manipulation happens in the dom, and javascript in Atom, which unless my memory is playing tricks on me means, many string copies.
The editor part of Atom is really a browser with a lot of markup. Theoretically it would be possible to change the backend code, and make the strings in Javascript in Atom have a different data structure backend, but that would break ECMAscript conformity I believe. There’s also no guarantee it will significantly reduce memory usage on small files since a lot of the overhead comes from mark up that shouldn’t be there to begin with.
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.
I’m also predicting node completion modules for both coffee and javascript. You might actually become more productive using it. And if you have a fast enough workstation with enough ram, why not? I can tell you though, my CPU design prof would probably look at me, mumble something in a nostalgic tone, and walk away.
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.