New world, same old problems. Fascinating to see how this parallels the way Emacs tackled this problem long ago.<p>- <a href="https://lwn.net/Articles/673724/" rel="nofollow">https://lwn.net/Articles/673724/</a><p>- <a href="https://news.ycombinator.com/item?id=11001796" rel="nofollow">https://news.ycombinator.com/item?id=11001796</a>
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.<p>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.<p>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.<p>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.
Is there any way not to conclude they have just been out designed/architected/optimized by Microsoft?<p>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.<p>It's a more interesting comparison since they're both bound by similar constraints, and building cross platform apps.<p>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.<p>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.
I'll provide a contrasting opinion to the comments saying startup time isn't important to them.<p>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.<p>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.<p>Once I'm done, I'll become horrified by the state of my desktop and proceed to close everything.<p>The next coding session starts fresh.<p>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.<p>I'm glad to see progress being made here.
Great article. Avid ST3 user here, but glad to hear about the improvements.<p>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)<p><a href="https://media.giphy.com/media/3ohzdTHkfj5ISAAPq8/source.gif" rel="nofollow">https://media.giphy.com/media/3ohzdTHkfj5ISAAPq8/source.gif</a><p>I should mention - my ST3 is heavily customized (28 plugins), while Atom and VSCode are absolute stock.
> Overall, on a stock installation, we made loading Atom almost <i>50% faster</i> and snapshots were a crucial tool that enabled some otherwise impossible optimizations.<p>Note that this hasn't shipped on stable yet, but is available on 1.17 beta.<p>The article mostly lists the various problems and associated optimizations. Concise & nice read.
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.<p><a href="https://github.com/google/snappy-start" rel="nofollow">https://github.com/google/snappy-start</a>
Emacs does a similar thing for startup time with dumping:<p>The Emacs dumper dispute
<a href="https://lwn.net/Articles/707615/" rel="nofollow">https://lwn.net/Articles/707615/</a>
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" :)
Unfortunately Atom is not on par with VSCode considering responsiveness.<p>There are a few more issues, <i>Emanuel Quimper</i> summarized in: <a href="https://equimper.github.io/2017/02/25/why-i-moved-away-from-atom-to-visual-studio-code-and-my-setup/" rel="nofollow">https://equimper.github.io/2017/02/25/why-i-moved-away-from-...</a> explaining why he moved from Atom to VSCode in detail.<p>A month ago there was an interesting submission in favor of Sublime Text 3. Mainly because of its incredible responsiveness: <a href="https://news.ycombinator.com/item?id=13928752" rel="nofollow">https://news.ycombinator.com/item?id=13928752</a> by <i>Tristan Hume</i>, comparing Vim, Spacemacs, Atom and Sublime Text. I highly recommend it.<p>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.<p>The zsh+tmux+vim toolchain is heavily customized, though: <a href="https://github.com/rscircus/dotfiles" rel="nofollow">https://github.com/rscircus/dotfiles</a>
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.
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.
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.
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.<p>[1]<a href="https://github.com/atom/electron-link" rel="nofollow">https://github.com/atom/electron-link</a>
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.
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...
I started this issue a long time ago, and it's been frozen since: <a href="https://github.com/electron/electron/issues/3041" rel="nofollow">https://github.com/electron/electron/issues/3041</a><p>Maybe now we can have actual source code protection?