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.
Improving startup time in Atom with V8 snapshots
31–40 of 173 posts
Re: Improving startup time in Atom with V8 snapshots
#32From 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.
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.
Re: Improving startup time in Atom with V8 snapshots
#33Earlier quoted context omitted.
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.
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]
Re: Improving startup time in Atom with V8 snapshots
#34I 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...
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`.
Re: Improving startup time in Atom with V8 snapshots
#35Or you can not have a text editor in a browser. :) Cool article regardless
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.
>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).
Re: Improving startup time in Atom with V8 snapshots
#36Earlier quoted context omitted.
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.
I hope you're right that this goes the way of emacs. I've been productive in emacs for 30 years, but I'm growing impatient for emacs to get a real programming language with lexical scoping like they were talking about doing with Scheme 20 years ago. Despite its lack of macros, JavaScript is arguably a better Lisp than Emacs Lisp. I've toyed with Atom a couple of times recently and am seriously thinking of switching.
Emacs Lisp in GNU Emacs has now lexical scoping...
Re: Improving startup time in Atom with V8 snapshots
#37Earlier quoted context omitted.
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.
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.
>In my experience all languages are essentially the same.
That's the problem: you don't seem to have enough experience.
Re: Improving startup time in Atom with V8 snapshots
#38Earlier quoted context omitted.
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.
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.
> This seems destined to go the way of emacs.
Hilarious. Emacs is one of the most successful programs of all time in my book. If I ever made an editor I'd pray every night that it'd be at least half as successful as Emacs.
Re: Improving startup time in Atom with V8 snapshots
#39I started this issue a long time ago, and it's been frozen since: https://github.com/electron/electron/issues/3041 Maybe now we can have actual source code protection?
Is compiling to WebAssembly an option to you?
Better than relying on memory snapshots.
Re: Improving startup time in Atom with V8 snapshots
#40I started this issue a long time ago, and it's been frozen since: https://github.com/electron/electron/issues/3041 Maybe now we can have actual source code protection?
if you want to protect your source code, don't use Javascript.
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.