
Improving startup time in Atom with V8 snapshots - io
http://blog.atom.io/2017/04/18/improving-startup-time.html
======
itp
New world, same old problems. Fascinating to see how this parallels the way
Emacs tackled this problem long ago.

\- [https://lwn.net/Articles/673724/](https://lwn.net/Articles/673724/)

\-
[https://news.ycombinator.com/item?id=11001796](https://news.ycombinator.com/item?id=11001796)

~~~
CalChris
I don't recall overcoming long startup times in _vi_ and _vim_. Did I miss
something?

~~~
itp
Emacs and Atom share the architectural aspect of implementing most of their
functionality in a higher-level language inside of an execution environment.
This has costs and benefits.

 _vi_ had a much simpler structure and much more limited feature set. _vim_ is
obviously a much more capable/flexible editor and has scripting support, but
is still predominantly written in C.

------
jnordwick
I'm way more worried about memory issues while running. Atom take up 1 gig+
with very little open. It pushes all my other tools out of RAM and into swap.
Switching to the browser to see documentation takes a few seconds if I'm
lucky.

Compiling a few more seconds to page in. Ssh a few more. Everything on my
laptop slows to a crawl as they fight for RAM with Atom taking up the way more
than it should.

I know the answer, "buy more RAM it's cheap", from the Atom people, but then
my browser people tell me the same thing. So do my interface people, and my
kernel people, and by the time I say "okay" to all of them, I'm out of RAM
again.

Application need to learn they aren't the only thing running. For some reason,
my machine seems to be getting slower and slower no matter how much I upgrade.

~~~
nkantar
> For some reason, my machine seems to be getting slower and slower no matter
> how much I upgrade.

I've been feeling this way for years, and I've mostly ascribed it to my faulty
perception. I figured that if things simply aren't _getting faster_ (i.e.,
they're not changing at all), I'm probably just _imagining_ them getting
slower.

But then I start wondering why _aren 't_ things getting faster...

~~~
cyknus
amdahl's law

------
WhitneyLand
Is there any way not to conclude they have just been out
designed/architected/optimized by Microsoft?

What a compliment to the VSC team that after all this work, Atom still doesn't
seem to match startup time, or more importantly perceived performance while
editing.

It's a more interesting comparison since they're both bound by similar
constraints, and building cross platform apps.

In the bad old days I once worked for a MS competitor where there were often
complaints of unfair competition. Most often around how knowledge of closed
sourced OS internals allowed optimization insights unavailable to others.

Not all MS devs are great for sure, but I'm inferring two things here. The VSC
team is pretty damn good, and that IP and institutional knowledge from decades
of investment in dev tools probably helps a bit.

~~~
matt4077
I'd offer the alternative theory that the VSCode team learnt everything they
could from Atom's past mistakes.

Speed is only one of the issues–I'm actually quite happy with Atom in that
regard. VSCode has a much more restricted API, and a more robust extension
system. With Atom, I always felt like extensions started interfering with each
other, and with the 'vanilla' experience. OTOH, I was exploring a few ideas,
such as inline rendering of comments in markdown, and that's really only
possible in Atom.

~~~
posguy
Sounds similar to the complaints about Firefox, though the only notable issues
I've run into with Atom have been related to shared file editing (and
resulting sync issues). If someone could just leverage etherpad lite with
Atom, it'd make me so happy!

~~~
matt4077
Firefox mostly has the problem that the open web suddenly became incredibly
important for Google: it's their platform, in the fight against Facebook and
Apple's iOS.

No organisation on the planet could compete with a team that Google considers
a core asset for actual survival.

Mozilla has made quite a few mistakes, but the times may change, and I sure
hope they'll be around when Google's incentives are no longer aligned with the
open web's.

~~~
posguy
Google can be out-competed, look at their attempts at social networks &
messaging/calling.

Google has lit dumpsters full of cash on fire in an effort to get anywhere
near Facebook, Twitter, Whatsapp, Viber or even Signal Private Messenger, and
yet their extremely fractured strategy that they have dumped R&D into still
has less users than any of those in their respective categories.

Mozilla can be competitive, akin to Darktable vs Adobe if Mozilla chooses to
be. No more mucking about bailing their friends out (ie: Pocket acquisition),
or trying to fight Google on hardware prices (Firefox OS's entire strategy).
Mozilla can create a playing field tilted in their favor, and force others to
compete on their turf rather than duking it out on Google or Chinese OEMs
turf.

------
fpgaminer
I'll provide a contrasting opinion to the comments saying startup time isn't
important to them.

I tend to work chaotically. I dive into a project and tackle whatever the
problem of the day is. The result is a sprawling mess of reference code pulled
up in different editor windows, documentation and google results spewing out
over 4 browser windows and 30 tabs, and just as many terminals managing VCS,
compilation, tests, etc.

It's not that I'm a messy coder or anything; it's just that when I'm focused
on a problem then my concern is about that problem, not about the growing heap
of reference material. The problem is particularly pronounced when working on
web applications, where I have to handle multiple code bases at once.

Once I'm done, I'll become horrified by the state of my desktop and proceed to
close everything.

The next coding session starts fresh.

So startup time is actually important to me. I have to say I'm annoyed by
VSCode's startup time. It starts up to a state where I can hit the menu and
start opening things very quickly, but isn't completely finished for another
couple seconds. Atom's in a very similar boat.

I'm glad to see progress being made here.

------
_arvin
Great article. Avid ST3 user here, but glad to hear about the improvements.

For anyone curious, I made a quick gif comparing startup times on my machine
for Sublime Text 3 (Build 3129), Atom (1.16.0), Atom Beta (1.17.0-beta2, the
one mentioned here), VSCode (1.11.2), and VSCode Insiders (1.12)

[https://media.giphy.com/media/3ohzdTHkfj5ISAAPq8/source.gif](https://media.giphy.com/media/3ohzdTHkfj5ISAAPq8/source.gif)

I should mention - my ST3 is heavily customized (28 plugins), while Atom and
VSCode are absolute stock.

~~~
draw_down
They all look to be within the same ballpark; none of those startup times
would be a problem for me, at least. But when I tried Atom it was noticeably
less responsive, which I have very little tolerance for. I haven't tried VS
Code. (I also use Sublime)

~~~
hoschicz
My experience is that VSCode is much more responsive than Atom.

Just a lot "snappier". Startup is not much of a problem, I don't open ordinary
files in VSCode or Atom by default (I use gedit for that)

------
rattray
> Overall, on a stock installation, we made loading Atom almost _50% faster_
> and snapshots were a crucial tool that enabled some otherwise impossible
> optimizations.

Note that this hasn't shipped on stable yet, but is available on 1.17 beta.

The article mostly lists the various problems and associated optimizations.
Concise & nice read.

------
rektide
Google long ago released Snappy Start, a tool for snapshotting processes,
saving the full state to disk, so new instances can be launched faster. This
is a more general Checkpoint-Restore capability than V8's impl and a bit
different, but definitely somewhere in the same field of computer technology.

[https://github.com/google/snappy-start](https://github.com/google/snappy-
start)

~~~
tyingq
Seems also related to CRIU, which does something similar, but for the purposes
of live migrating a process from one host to another.
[https://criu.org/Main_Page](https://criu.org/Main_Page)

~~~
rektide
Yeah I probably should have lead with CRIU. It's been a longstanding ongoing
project of excellence. A lot of people who work or worked (unsure of
breakdown) on OpenVZ have been cranking on this for many year.

Work from the CRIU crew started getting upstreamed almost exactly four years
ago, breaking some initial resistance to the tech needed for CRIU-
[https://mobile.twitter.com/__criu__/status/58727373960931328...](https://mobile.twitter.com/__criu__/status/587273739609313281)
[https://criu.org/History](https://criu.org/History)

It's interesting the breakdown in sell- CRIU is a swiss army knife of a tool,
whereas Snappy Start and V8 Snapshots seem targetted and marketted largely
towards fast "initialization" concerns.

------
cschmidt
Emacs does a similar thing for startup time with dumping:

The Emacs dumper dispute
[https://lwn.net/Articles/707615/](https://lwn.net/Articles/707615/)

------
patrickg_zill
Funny how everything old is new again. Dumping an image, something seen with
Emacs, and with SmallTalk and LISP languages since before Emacs was derided as
"eight megs and constantly swapping" :)

------
rawland
Unfortunately Atom is not on par with VSCode considering responsiveness.

There are a few more issues, _Emanuel Quimper_ summarized in:
[https://equimper.github.io/2017/02/25/why-i-moved-away-
from-...](https://equimper.github.io/2017/02/25/why-i-moved-away-from-atom-to-
visual-studio-code-and-my-setup/) explaining why he moved from Atom to VSCode
in detail.

A month ago there was an interesting submission in favor of Sublime Text 3.
Mainly because of its incredible responsiveness:
[https://news.ycombinator.com/item?id=13928752](https://news.ycombinator.com/item?id=13928752)
by _Tristan Hume_ , comparing Vim, Spacemacs, Atom and Sublime Text. I highly
recommend it.

My workflow now looks like this: VSCode+Plugins replaces my zsh+tmux+vim
toolchain when running on AC. On battery zsh+tmux+vim provide VSCode+Plugins
functionality with less beautiful gfx but unmatchable battery lifetime.

The zsh+tmux+vim toolchain is heavily customized, though:
[https://github.com/rscircus/dotfiles](https://github.com/rscircus/dotfiles)

------
pducks32
I love it when new problems can be solved in old ways. In physics we say there
aren't 10,000 problems there are just 10,000 manifestations of 5. And it
really seems like that's true here. Maybe we should stop laying off people for
being old lol.

~~~
chronic940
The industry is doing fine without the old workers with outdated skillsets.
Correctness does not matter as much as velocity to release.

~~~
javajosh
No, industry is pushing food around the plate, and has been for some time. It
must have been amusing (to some) to see WebSockets arise, when TCP sockets do
the same thing. Why is a new standard needed? Because firewalls block
everything but port 80 and 443, and every other program that uses non-HTTP
sockets has all-but-died off (with the exception of some games).

90% of the "innovation" in application programming is just an exercise in
combinatorial virtualization.

(That said, it's not all bad. The browser has had a remarkable and wonderful
effect on GUI application architecture that probably wouldn't have happened
elsewhere.)

------
agentultra
Interesting! Image-based development is actually really useful for many
applications. It would be interesting to see V8 support this more generally.
It's something I quite like about CL and Smalltalk systems.

------
foota
From the article it sounds like they're basing these tests off probably their
dev machines. Seems like they should be trying this out on slower machines.

~~~
Klathmon
It sounds to me like they are testing it on slower machines (specifically
slower hard drives), as they specifically call out one of the "smaller"
optimizations as having a significant impact on machines with slower hard
drives.

~~~
foota
It sounded to me like they were extrapolating though, "This resulted in a
~100ms improvement on a fast machine with an SSD but, since most of this work
was I/O bound, we expect it to be even more noticeable on slower hardware."
This in fact was where I drew the inspiration for my comment from.

------
alfonsodev
From the article, they have the electron-link[1] module that anyone can use in
a electron app to get the same functionality working. Not sure how it plays
with webpcack.

[1][https://github.com/atom/electron-link](https://github.com/atom/electron-
link)

------
z3t4
Minifying the code can also speed up the startup time ... Another trick is to
auto-start the app and bring it to the background (invisible). Then when the
user "starts" it, just make it visible.

~~~
nsebban
Your solution is a good one, but I get kind of sad when I remember the context
: launching a text editor :/

------
CJefferson
I wish atom would just add preloading. I be happy to always have a hidden,
sleeping window ready to pop to front on request. There must be some reason
this is harder than I imagine...

~~~
bronson
You can basically do that now: just don't quit. If you start Atom and it
discovers that it's already running, it tells the running process to handle
the request. It even honors environment variables and flags like --dev.

For example, starting Atom cold on my medium-sized project (by running `atom
.` in the base dir) takes 6 seconds. If I close all windows but leave Atom
running, do something else for a while, and then run that command again, it
takes 3 seconds.

(That's still a disturbingly long time... but it's quick enough once launched.
I like Atom enough that I can live with it for now.)

Edit: just tried the beta. It's a little quicker: 4.5ish seconds and 2
seconds. Still OK for long-term coding but too slow to be $EDITOR for things
like `git commit`.

~~~
michaelmrose
This is really simple procedure that should take like a millisecond why does
it take seconds?

~~~
Klathmon
I always hated this argument. It feels to me like someone is complaining why a
train can't go from 0-60 in 10 seconds while many cars can. The answer is
always "because that's not what it's designed to do".

Regardless of how you feel about it, the team behind Atom made a design
decision to sacrifice performance to gain a large amount of other benefits
("easier" higher level language, easy cross platform support, extremely easy
to write plugins for it from it's target "demographic", etc...).

Because of those architecture choices, things like spawning a new window
aren't as easy and straightforward as they might be in another architecture.

So just because you want a method of transportation that goes from 0-60 in 10
seconds, doesn't mean that all methods of transportation need to go from 0-60
in 10 seconds. And just because a method of transportation can't go from 0-60
in 10 seconds doesn't mean the designers were lazy or cut corners, it just
means that they prioritised other things, and are solving different problems.

------
rcfox
Oh man, I wish I could use snapshots in the browser. In some extreme cases,
I'm dealing with multi-minute startup times.

~~~
markdog12
I think v8 does cache machine code in some cases. There are a couple of flags
in chrome://flags you'll want to look at:

V8 Caching Mode, V8 caching strategy for CacheStorage

[https://v8project.blogspot.ca/2015/07/code-
caching.html](https://v8project.blogspot.ca/2015/07/code-caching.html)

Edit: Not the same as snapshots mentioned in the article

------
penagwin
I started this issue a long time ago, and it's been frozen since:
[https://github.com/electron/electron/issues/3041](https://github.com/electron/electron/issues/3041)

Maybe now we can have actual source code protection?

~~~
merkaloid
if you want to protect your source code, don't use Javascript.

~~~
MichaelGG
>don't distribute your programs

That's what it really comes down to. From what I can see, it's mostly an
emotional response. I'd be surprised if code/binary obfuscation is a net win
in general.

I've had to disabuse developers of this idea. One distributed binaries that
weren't quite valid but ran on the CLR, though not Mono. A 10 line script was
enough to remove the invalid sequences. What did the developer gain in this
case? An extra build step, undoubtedly more than one bug, and in the end, no
"protection".

~~~
penagwin
I agree with the idea that anything can be reverse engineered. However
electron by default has plain text javascript code. I'd like to prevent people
from editing plain text (!!!) to evade my licensing check!

~~~
porpoisemonkey
For what it's worth I agree with the Electron dev's decision to close the
ticket. They don't seem to have the same use case as you and are under no
obligation to support it.

There's also the unstated issue of ongoing support for the feature. If they
put in code obfuscation they'll be obligated to make sure that it provides
adequate protections to avoid a deluge of "someone hacked my obfuscated code"
type tickets. What constitutes "adequate protections" will have to be updated
over time as more advanced techniques are discovered for reversing out the
code.

Combined with the performance drops that were clearly outlined by the Electron
devs it would seem like a code obfuscation feature could be a really big waste
of time.

------
iynere
just tried the beta its still pretty slow :(

~~~
krisdol
About 10 seconds of startup opening a directory, from terminal to loaded
workspace. I'm on a MacBook Pro (Retina, 13-inch, Early 2015). I have 76
community plugins installed.

~~~
bronson
76? Daaam. I thought I was overdoing it at 53. (If anyone wants to check:

    
    
        ls ~/.atom/packages | wc -l  # minus 1 for the README
    

Have you checked Timecop? (cmd-shift-p, "timecop") Might be a few you can do
without.

~~~
krisdol
I have too many. But it works well for me. I've worked on too many languages
with the same editor, so I've got... Front and back-end JS tools (linting,
tern autocompletion, builds); clojure with a repl and parinfer, paredit; some
rust and elm plugins that can probably go since I just experimented with those
mainly. Linter for terraform. I also use atom for general note taking, so I've
got a couple plugins for that.

------
madamelic
Or you can not have a text editor in a browser. :)

Cool article regardless

~~~
chickenfries
Must every thread about VSCode and Atom start the same way? It's a trade off:
performance for a cross platform JavaScript app development. If that is a
tradeoff you don't have to make, don't do it. Atom and VSCode have made that
tradeoff. I don't know what rehashing this can possibly accomplish.

~~~
coldtea
> _Must every thread about VSCode and Atom start the same way_

If many people believe this is the case, why not? All articles get some common
types of responses based on the topic, this is just one topic/response combo
that you happen to disagree with.

> _It 's a trade off: performance for a cross platform JavaScript app
> development._

It's an unnecessary tradeoff.

If a single developer can create ST from scratch for Windows, OS X and Linux,
then surely GitHub or Microsoft (for VSCode) can create a cross platform
native set of UI components in C or C++, wrap them, and have the rest of the
development (plugins etc) happen in JS (to keep the familiar language, easy
access to npm modules, etc).

~~~
dstaley
If this was truly that simple, don't you think someone would have already done
it? Furthermore, is there even an actively maintained, open source, cross
platform, development-focused text editor with native UI components?

~~~
coldtea
> _If this was truly that simple, don 't you think someone would have already
> done it?_

Someone already has done it. An one-man-shop built Sublime Text by himself.

Surely it's not having JS as an extension language as opposed to Python (the
only difference between ST and what I propose) that's making it difficult.

> _Furthermore, is there even an actively maintained, open source, cross
> platform, development-focused text editor with native UI components?_

There's a "cross platform, development-focused text editor with native UI
component" that's working great.

Whether there's an open source editor like that is orthogonal, since what I'm
discussing is whether is technically feasible to create such a browser -- and
the existence of ST proves that it is (and that's by a single developer: with
resources such as that GitHub or even better MS, have, it would be much
easier).

The choice of license is just a decision after that.

~~~
nilliams
I think the developer behind Sublime Text is widely recognised as an outlier.

>> "Sublime Text 2 is mostly coded in C++ and uses a custom UI toolkit." ...
[0]

How many other devs/teams are going to reasonably take that on.

(And how do you think the debugging story of his custom framework compares to
Chrome Devtools).

[0] [http://stackoverflow.com/a/9201645](http://stackoverflow.com/a/9201645)

~~~
frou_dh
> How many other devs/teams are going to reasonably take that on?

This strikes me as a sort of devolving-human standpoint that might lead to
someone in 2050 asking how anybody could possibly walk 10 miles unassisted.

In the past, small teams of talented developers have written an entire game +
game engine + associated tools from scratch, countless times.

Doing in-depth custom UI development for the desktop as part of creating a
text editor does not bin as 'Mountain-moving; Don't even try' difficulty.

------
chrshawkes
I thought everybody moved over to Visual Studio Code by now.

