9 ms·

Improving startup time in Atom with V8 snapshots

212 points by io 9y ago

madamelic 9y ago
Or you can not have a text editor in a browser. :) Cool article regardless
- chickenfries 9y ago
  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.
  - hartator 9y ago
    It's a bit the same issue then something like rails. Easy in the short run, but when you starting doing advance optimization - likw those - you wonder why not rewrite in a more performance oriented language.
    - Klathmon 9y ago
      Because the whole point of the editor is the web stack. The fact that it's built on web technologies, and web developers can make plugins easily and quickly and can hack on the core code is the entire reason for it's existence, and why it's so popular. If you rewrite it in another stack, you basically just created an entirely new editor which isn't compatible in just about every way with atom.
    - Touche 9y ago
      Great comparison. In both cases choosing the language that helps you launch quickly is almost always the right decision. You can always scale later. Better to find out if your app is even going to be a success, first.
  - ruleabidinguser 9y ago
    I don't really see what the benefit of JavaScript app development is. You don't need to use electron and JavaScript for portability, as far as I'm aware. For example, I know of Qt, and I'm sure there are other toolkits in other similarly mature platforms. This seems destined to go the way of emacs. This is always what happens when an idealistic perspective wins out over a practical one in a development team.
    - chickenfries 9y ago
      It's a benefit if your engineers already know JavaScript, obviously. Also, emacs is one of the most successful text editors so I'm not sure I get your comparison.
      - ruleabidinguser 9y ago
        I don't consider emacs successful. Succesful among fanatics, maybe, but I don't consider is valuable to a serious programmer. Also, surely it's not that hard to switch languages? In my experience all languages are essentially the same.
        deleted 9y ago
        [deleted]
        coldtea 9y ago
        >In my experience all languages are essentially the same. That's the problem: you don't seem to have enough experience.
        ruleabidinguser 9y ago
        I dont seem to have much experience? Based on what? For having a different view than you? Isnt that a little naive? So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week. How much experience do you think I have? I've used plenty of languages, and I'm well aware that there are nuances.
  - coldtea 9y ago
    >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 9y ago
      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?
      - jen20 9y ago
        IntelliJ does a good job of it without resorting to Electron.
        dstaley 9y ago
        IntelliJ doesn't use native UI components though. Furthermore, Atom can open a single file in 3s, whereas opening the same file in IntelliJ takes 11s (these numbers are from cold starts). This is with clean installs of both IDEs on a 2016 MacBook Pro.
        cwyers 9y ago
        No, it just resorts to the freaking JVM, which is not any more lightweight or native than Electron apps.
        Veratyr 9y ago
        I don't think that's true. The JVM is far closer to native code than Javascript, both technically and in terms of actual performance. Here's some synthetic number crunching benchmarks: https://benchmarksgame.alioth.debian.org/u64q/javascript.html https://benchmarksgame.alioth.debian.org/u64q/javascript.htm... Even on the I/O heavy workloads that Node/V8 should be able to handle best, Java is ahead: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ And yes, there are many Java apps that like to eat memory but I don't believe it's as bad or worse than V8/Electron and I don't believe Java is as inherently memory hungry as V8/Electron.
rcfox 9y ago
Oh man, I wish I could use snapshots in the browser. In some extreme cases, I'm dealing with multi-minute startup times.
- rattray 9y ago
  What kind of application are you building?
  - rcfox 9y ago
    Electronics design software. :) Most of the time is spent doing fine collisions with shapes coming out of an R-tree to build up a connection graph. For the vast majority of designs, it's fast. For very dense, imported designs, it can get slow. (No two tools keep data in the same form, so translating leads to inefficiencies.)
    - randomUser4 9y ago
      I recently evaluated all online EDAs that I could find. Some of them where quite slow because they used SVG for rendering. I would love to see your tool, too. Unfortunately, I couldn't find it in your profile. Do you have a link?
      - rcfox 9y ago
        https://upverter.com/ https://upverter.com/ We use canvas, which saves us from the SVG DOM, but it also means managing the scene ourselves. If I ever get some time, I'd like to experiment with a WebGL renderer...
        Sophistifunk 9y ago
        Do you have any blog posts or similar about how you're managing the scene graph? I've been thinking a lot about building a scene graph lately, and coordinate -> component mapping seems expensive in time and/or memory depending on how you do it.
rattray 9y ago
> 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.
CJefferson 9y ago
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 9y ago
  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`.
  - CJefferson 9y ago
    You are right, it is things like 'git commit' where I'd like it to be faster -- and that's where an invisible window feels like the right option. Start opening another one whenever I start using the last hidden one.
  - michaelmrose 9y ago
    This is really simple procedure that should take like a millisecond why does it take seconds?
    - Klathmon 9y ago
      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.
cschmidt 9y ago
Emacs does a similar thing for startup time with dumping: The Emacs dumper dispute https://lwn.net/Articles/707615/ https://lwn.net/Articles/707615/
itp 9y ago
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
- bodyfour 9y ago
  And sendmail long ago (pre-sendmail 8) -- it used to dump out a binary image of itself after parsing sendmail.cf to speed up startup.
- bonzini 9y ago
  It also looks very similar to a Smalltalk image...
- CalChris 9y ago
  I don't recall overcoming long startup times in vi and vim. Did I miss something?
  - itp 9y ago
    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.
  - omaranto 9y ago
    Not necessarily. You might just be extra patient, or not use many plugins, or only use well behaved ones that down slow down startup that much. I remember years ago when I used Vim I had pretty slow start up time for a while but narrowed the problem down to one plugin I decided I could live without (can't remember which one it was, though).
- lispm 9y ago
  Let's not forget Lisp I. Lisp I Programmer's Manual, 1960, Page 67 > ... that immediately after all the triplets have been > evaluated the state of the memory as it stands is read out > onto tape 8 as the new "base" image for the memory. ... http://history.siam.org/sup/Fox_1960_LISP.pdf http://history.siam.org/sup/Fox_1960_LISP.pdf
deleted 9y ago
[deleted]
penagwin 9y ago
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 9y ago
  if you want to protect your source code, don't use Javascript.
  - fnord123 9y ago
    I guess "source code protection" is for distributing plugins for Atom without distributing the source so the code isn't accessible. So I would call this "source code concealing". In any event, this could be done with WASM.
    - penagwin 9y ago
      I actually needed this with it's framework electron. Unfortunately I haven't yet found a method of compiling coffeescript (or javascript) with WASM. I'm just asking for concealing against my licensing code from being in a text file.
  - MichaelGG 9y ago
    >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 9y ago
      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!
agentultra 9y ago
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.
iynere 9y ago
just tried the beta its still pretty slow :(
- krisdol 9y ago
  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 9y ago
    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.
    - gjtorikian 9y ago
      `apm list --installed --bare` is also a good one-liner.
    - wingworks 9y ago
      And here I was thinking I needed to start slimming down at 23.
    - krisdol 9y ago
      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.
    - deleted 9y ago
      [deleted]
patrickg_zill 9y ago
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" :)
jbeja 9y ago
Better, never startup what doesn't need to be.
alfonsodev 9y ago
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
foota 9y ago
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 9y ago
  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 9y ago
    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.
rektide 9y ago
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 9y ago
  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 9y ago
    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/587273739609313281 https://mobile.twitter.com/__criu__/status/58727373960931328... 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.
deleted 9y ago
[deleted]
jnordwick 9y ago
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.
- BinaryIdiot 9y ago
  > I'm way more worried about memory issues while running. Same here. Start-up time is important when the average user is hitting a web app or application but for developers? We open something once and then keep it open pretty much all day. Unless I'm an edge case I'd suspect start-up time is mostly meaningless to developers with long running developer tools. At the same time we always have tons of tools open at once so we need as much memory as possible because once things hit the swap the performance degrades terribly.
  - jnordwick 9y ago
    If Atom ran like vim, I'd take 60 seconds+ of startup time. If it ran like ed, maybe even an hour. I probably spend more time hitting backspace when typing 'atom' than they saved in startup time.
- lurker456 9y ago
  same here, I've switched away from Atom for that reason.
- moron4hire 9y ago
  I don't get this. I've built text editors in JavaScript. I've built Electron apps. Granted, I've never built a text editor in Electron. But it's gotta be some trivial combination of my past experiences. I don't understand why Atom is such a pig.
_arvin 9y ago
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 9y ago
  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 9y ago
    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)
  - kiliankoe 9y ago
    Showing a window is in the same ballpark, but being ready for input is something else. On Sublime this is basically the same instant. On VSC and Atom it takes a bit longer to actually render a cursor.
- fpgaminer 9y ago
  Nice comparison! Would be even better to see them all side-by-side.
pducks32 9y ago
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 9y ago
  The industry is doing fine without the old workers with outdated skillsets. Correctness does not matter as much as velocity to release.
  - javajosh 9y ago
    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.)
chrshawkes 9y ago
I thought everybody moved over to Visual Studio Code by now.
z3t4 9y ago
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 9y ago
  Your solution is a good one, but I get kind of sad when I remember the context : launching a text editor :/
fpgaminer 9y ago
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.
WhitneyLand 9y ago
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 9y ago
  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 9y ago
    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!
    - vvggff 9y ago
      Would you pay?
    - matt4077 9y ago
      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.
rawland 9y ago
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-atom-to-visual-studio-code-and-my-setup/ https://equimper.github.io/2017/02/25/why-i-moved-away-from-... 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

212 points by io 9y ago

madamelic 9y ago

Or you can not have a text editor in a browser. :) Cool article regardless

chickenfries 9y ago
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.
- hartator 9y ago
  It's a bit the same issue then something like rails. Easy in the short run, but when you starting doing advance optimization - likw those - you wonder why not rewrite in a more performance oriented language.
  - Klathmon 9y ago
    Because the whole point of the editor is the web stack. The fact that it's built on web technologies, and web developers can make plugins easily and quickly and can hack on the core code is the entire reason for it's existence, and why it's so popular. If you rewrite it in another stack, you basically just created an entirely new editor which isn't compatible in just about every way with atom.
  - Touche 9y ago
    Great comparison. In both cases choosing the language that helps you launch quickly is almost always the right decision. You can always scale later. Better to find out if your app is even going to be a success, first.
- ruleabidinguser 9y ago
  I don't really see what the benefit of JavaScript app development is. You don't need to use electron and JavaScript for portability, as far as I'm aware. For example, I know of Qt, and I'm sure there are other toolkits in other similarly mature platforms. This seems destined to go the way of emacs. This is always what happens when an idealistic perspective wins out over a practical one in a development team.
  - chickenfries 9y ago
    It's a benefit if your engineers already know JavaScript, obviously. Also, emacs is one of the most successful text editors so I'm not sure I get your comparison.
    - ruleabidinguser 9y ago
      I don't consider emacs successful. Succesful among fanatics, maybe, but I don't consider is valuable to a serious programmer. Also, surely it's not that hard to switch languages? In my experience all languages are essentially the same.
      - deleted 9y ago
        [deleted]
      - coldtea 9y ago
        >In my experience all languages are essentially the same. That's the problem: you don't seem to have enough experience.
        ruleabidinguser 9y ago
        I dont seem to have much experience? Based on what? For having a different view than you? Isnt that a little naive? So as far as actually talking about my point goes, what exactly am I missing? There are small differences but I've never seen a language that I couldn't get up and going in over the course of a week. How much experience do you think I have? I've used plenty of languages, and I'm well aware that there are nuances.
- coldtea 9y ago
  >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 9y ago
    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?
    - jen20 9y ago
      IntelliJ does a good job of it without resorting to Electron.
      - dstaley 9y ago
        IntelliJ doesn't use native UI components though. Furthermore, Atom can open a single file in 3s, whereas opening the same file in IntelliJ takes 11s (these numbers are from cold starts). This is with clean installs of both IDEs on a 2016 MacBook Pro.
      - cwyers 9y ago
        No, it just resorts to the freaking JVM, which is not any more lightweight or native than Electron apps.
        Veratyr 9y ago
        I don't think that's true. The JVM is far closer to native code than Javascript, both technically and in terms of actual performance. Here's some synthetic number crunching benchmarks: https://benchmarksgame.alioth.debian.org/u64q/javascript.html https://benchmarksgame.alioth.debian.org/u64q/javascript.htm... Even on the I/O heavy workloads that Node/V8 should be able to handle best, Java is ahead: https://www.techempower.com/benchmarks/ https://www.techempower.com/benchmarks/ And yes, there are many Java apps that like to eat memory but I don't believe it's as bad or worse than V8/Electron and I don't believe Java is as inherently memory hungry as V8/Electron.

rcfox 9y ago

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

rattray 9y ago
What kind of application are you building?
- rcfox 9y ago
  Electronics design software. :) Most of the time is spent doing fine collisions with shapes coming out of an R-tree to build up a connection graph. For the vast majority of designs, it's fast. For very dense, imported designs, it can get slow. (No two tools keep data in the same form, so translating leads to inefficiencies.)
  - randomUser4 9y ago
    I recently evaluated all online EDAs that I could find. Some of them where quite slow because they used SVG for rendering. I would love to see your tool, too. Unfortunately, I couldn't find it in your profile. Do you have a link?
    - rcfox 9y ago
      https://upverter.com/ https://upverter.com/ We use canvas, which saves us from the SVG DOM, but it also means managing the scene ourselves. If I ever get some time, I'd like to experiment with a WebGL renderer...
      - Sophistifunk 9y ago
        Do you have any blog posts or similar about how you're managing the scene graph? I've been thinking a lot about building a scene graph lately, and coordinate -> component mapping seems expensive in time and/or memory depending on how you do it.

rattray 9y ago

> 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.

CJefferson 9y ago

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 9y ago
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`.
- CJefferson 9y ago
  You are right, it is things like 'git commit' where I'd like it to be faster -- and that's where an invisible window feels like the right option. Start opening another one whenever I start using the last hidden one.
- michaelmrose 9y ago
  This is really simple procedure that should take like a millisecond why does it take seconds?
  - Klathmon 9y ago
    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.

cschmidt 9y ago

Emacs does a similar thing for startup time with dumping: The Emacs dumper dispute https://lwn.net/Articles/707615/ https://lwn.net/Articles/707615/

itp 9y ago

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

bodyfour 9y ago
And sendmail long ago (pre-sendmail 8) -- it used to dump out a binary image of itself after parsing sendmail.cf to speed up startup.
bonzini 9y ago
It also looks very similar to a Smalltalk image...
CalChris 9y ago
I don't recall overcoming long startup times in vi and vim. Did I miss something?
- itp 9y ago
  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.
- omaranto 9y ago
  Not necessarily. You might just be extra patient, or not use many plugins, or only use well behaved ones that down slow down startup that much. I remember years ago when I used Vim I had pretty slow start up time for a while but narrowed the problem down to one plugin I decided I could live without (can't remember which one it was, though).
lispm 9y ago
Let's not forget Lisp I. Lisp I Programmer's Manual, 1960, Page 67 > ... that immediately after all the triplets have been > evaluated the state of the memory as it stands is read out > onto tape 8 as the new "base" image for the memory. ... http://history.siam.org/sup/Fox_1960_LISP.pdf http://history.siam.org/sup/Fox_1960_LISP.pdf

deleted 9y ago

[deleted]

penagwin 9y ago

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 9y ago
if you want to protect your source code, don't use Javascript.
- fnord123 9y ago
  I guess "source code protection" is for distributing plugins for Atom without distributing the source so the code isn't accessible. So I would call this "source code concealing". In any event, this could be done with WASM.
  - penagwin 9y ago
    I actually needed this with it's framework electron. Unfortunately I haven't yet found a method of compiling coffeescript (or javascript) with WASM. I'm just asking for concealing against my licensing code from being in a text file.
- MichaelGG 9y ago
  >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 9y ago
    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!

agentultra 9y ago

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.

iynere 9y ago

just tried the beta its still pretty slow :(

krisdol 9y ago
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 9y ago
  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.
  - gjtorikian 9y ago
    `apm list --installed --bare` is also a good one-liner.
  - wingworks 9y ago
    And here I was thinking I needed to start slimming down at 23.
  - krisdol 9y ago
    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.
  - deleted 9y ago
    [deleted]

patrickg_zill 9y ago

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" :)

jbeja 9y ago

Better, never startup what doesn't need to be.

alfonsodev 9y ago

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

foota 9y ago

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 9y ago
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 9y ago
  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.

rektide 9y ago

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 9y ago
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 9y ago
  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/587273739609313281 https://mobile.twitter.com/__criu__/status/58727373960931328... 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.

deleted 9y ago

[deleted]

jnordwick 9y ago

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.

BinaryIdiot 9y ago
> I'm way more worried about memory issues while running. Same here. Start-up time is important when the average user is hitting a web app or application but for developers? We open something once and then keep it open pretty much all day. Unless I'm an edge case I'd suspect start-up time is mostly meaningless to developers with long running developer tools. At the same time we always have tons of tools open at once so we need as much memory as possible because once things hit the swap the performance degrades terribly.
- jnordwick 9y ago
  If Atom ran like vim, I'd take 60 seconds+ of startup time. If it ran like ed, maybe even an hour. I probably spend more time hitting backspace when typing 'atom' than they saved in startup time.
lurker456 9y ago
same here, I've switched away from Atom for that reason.
moron4hire 9y ago
I don't get this. I've built text editors in JavaScript. I've built Electron apps. Granted, I've never built a text editor in Electron. But it's gotta be some trivial combination of my past experiences. I don't understand why Atom is such a pig.

_arvin 9y ago

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 9y ago
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 9y ago
  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)
- kiliankoe 9y ago
  Showing a window is in the same ballpark, but being ready for input is something else. On Sublime this is basically the same instant. On VSC and Atom it takes a bit longer to actually render a cursor.
fpgaminer 9y ago
Nice comparison! Would be even better to see them all side-by-side.

pducks32 9y ago

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 9y ago
The industry is doing fine without the old workers with outdated skillsets. Correctness does not matter as much as velocity to release.
- javajosh 9y ago
  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.)

chrshawkes 9y ago

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

z3t4 9y ago

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 9y ago
Your solution is a good one, but I get kind of sad when I remember the context : launching a text editor :/

fpgaminer 9y ago

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.

WhitneyLand 9y ago

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 9y ago
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 9y ago
  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!
  - vvggff 9y ago
    Would you pay?
  - matt4077 9y ago
    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.

rawland 9y ago

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-atom-to-visual-studio-code-and-my-setup/ https://equimper.github.io/2017/02/25/why-i-moved-away-from-... 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