7 ms·
Speeding up Electron apps by using V8 snapshots in the main process
- jauntywundrkind 2y agoThere's so so much goodness available from tapping vm's as such, as virtual machines that we might do cool checkpoint/restore off on. Java has had some similar abilities to rebuild the pre-compiled stdlib with whatever else you want already included. So, each Java instance both boots faster & has less overhead. Forgetting the name though! Node has options too! https://nodejs.org/api/cli.html#--build-snapshot https://nodejs.org/api/cli.html#--build-snapshot
- Skinney 2y agoProblem with Node is that the snapshot functionality has several severe limitations. Copy pasted from NodeJS docs: --- Currently the support for run-time snapshot is experimental in that: 1. User-land modules are not yet supported in the snapshot, so only one single file can be snapshotted. Users can bundle their applications into a single script with their bundler of choice before building a snapshot, however. 2. Only a subset of the built-in modules work in the snapshot, though the Node.js core test suite checks that a few fairly complex applications can be snapshotted. Support for more modules are being added. If any crashes or buggy behaviors occur when building a snapshot, please file a report in the Node.js issue tracker and link to it in the tracking issue for user-land snapshots. --- (1) is fine as you can use a bundler to work around it. (2) can't, as far as I know, be worked around.
- ilrwbwrkhv 2y agoWill this make slack work fast? That piece of crap even cannot resize efficiently on a Mac m3 pro.
- onedognight 2y agoSlack is just a website you can open in a tab/window. You don’t need to add Electron your browser diet to use it.
- samtheprogram 2y agoIt’s desktop app that’s built on Electron. Although, yes, when I’m on resourced constrained machines, I open it in a Firefox tab.
- magicalhippo 2y agoI run Slack in a Firefox window, and I had to add an extension to reload the page every 15 minutes due to live leaks. Would cause FF to eat tens of GB, making FF sluggish until it crashed...
- hsbauauvhabzb 2y agoI see electron get a lot of hate, and don’t get me wrong, I empathise with your issue, but has anyone ever documented an analysis on whether these sorts of things are caused by electron itself, or just bad application logic which just happens to be running under electron?
- eric-hu 2y agoAfter using VS Code for a while coming from vim, I’m inclined to say it’s bad application programming.
- v3ss0n 2y agoThere are many places VIM/Neovim are a lot slower / less responsive than VSCode. - Syntax Colorization of large source files. - Auto-Completion Performance - Rendering on Navigation when line lengths are very long. Only thing Vim/NVim faster is Start-Up speed. If someone care about speed actually, try Kate and Zed
- hsbauauvhabzb 2y agoI think the parent was calling vscode good from a performance perspective.
- eric-hu 2y agoIndeed I was. I mentioned vim because I’m used to that level of performance and VS Code is on par. I have experienced sluggishness with Slack, so I meant Slack likely has performance issues due its application code rather than its Electron dependency.
- tomphoolery 2y agoAs someone who's made a few Electron apps in the past, I can say that it has a lot more to do with what you're putting into the app itself than the runtime shell you're working with. It's not impossible to make an Electron app that's very efficient, to the point where people probably wouldn't realize it uses Electron unless they opened the app itself and poked through the source code. That said, due to Electron being a layer above the actual application stuff that's doing the "real" work, it's a lot harder to sniff out performance problems and especially to reproduce them on all platforms. So I wouldn't call this "bad application logic", I would say that it probably has more to do with using older (and deprecated) APIs to handle certain things like resizing the window, which could be replaced with better ones if the devs at Slack were able to easily see that this was causing problems for people. Unfortunately, Electron does make that a bit harder to do. Basically...I'd say this has more to do with the fact that Slack's development team doesn't get enough control over their applications in order to make things like this happen faster.
- guappa 2y agoI use localslackirc at work, so I don't get overwhelmed. But it's certainly not for everyone. I'm the only one in my company who uses it (AFAIK).
- dgl 2y agoWhat's old is new again. Emacs has long done snapshots a bit like this, albeit in a hacky way[1][2] [1]: https://lwn.net/Articles/673724/ https://lwn.net/Articles/673724/ (2016) [2]: https://lwn.net/Articles/707615/ https://lwn.net/Articles/707615/ (2016) and discussion here: https://news.ycombinator.com/item?id=13073566 https://news.ycombinator.com/item?id=13073566
- dig1 2y agoJVM has a similar thing called appcds (https://docs.oracle.com/en/java/javase/17/vm/class-data-sharing.html https://docs.oracle.com/en/java/javase/17/vm/class-data-shar...) since JDK 10 and you can also use Criu (https://criu.org https://criu.org) for this, at least I used it for some JVM apps before. Don't forget that Common Lisp and Smalltak implementations have had this since the beginning of time :D
- jmaker 2y agoThere’s also OpenJDK Project CRaC (based on CRIU) and AWS Lambda SnapStart (leveraging CRaC).
- p_l 2y agoIBM J9 also had explicit support for sharing code heap between multiple applications, and there were ways to preload code into older Oracle JDK's than 10 by abusing iirc bootstrap classpath?
- lispm 2y agoLisp I in 1960 did this, too.
- bhawks 2y agoAndroid uses a similar approach to launch apps quickly. When you request to start an app the zygote process forks and the child does the work of starting the app. It allows the children to share all the upfront initialization that is done once per boot.
- saagarjha 2y agoiOS does this too now.
- lxgr 2y agoDo you know how Apple calls their version? I’m curious how they implement it.
- diggan 2y agoNot parent, but maybe they are possibly referring to "State Restoration"?
- saagarjha 2y agodyld closures and prewarming actually
- lxgr 2y agoThank you! That sounds pretty different in implementation from zygote processes though: Zygote processes do go through the initialization once, but then clone that pre-initialized state via forking. That makes launches faster, but importantly also reduces memory usage by sharing effectively read-only dirty memory across all processes (e.g. everything read into memory by each process via read() instead of memory mapping). dyld closures seem to be caching process-specific linking precalculations, and prewarming just opportunistically (pre-)launches an app in case it's needed later. Same effect (faster launch time), but probably no memory savings, and a very different implementation.
- Scarlxd 2y agoThanks, this really helps! We are planning to improve the performance of our Electron app.
- xenospn 2y agoHopefully this applies to VSCode as well. I try to avoid Electron apps at all costs, but sometimes there's no other choice.
- eknkc 2y agoVsCode surprises me to be honest. Besides slow starts, it does not seem to be suffering from any major slowdown for me. I’d expect that thing to get bloated pretty far, really fast.
- gardaani 2y agoVS Code does become slower for me on my MacBook M1. I typically don't restart the app unless I have to. After few days of usage, scrolling the code area becomes so slow (<20fps) that I have to restart the app. I haven't experienced such slowdown in other IDEs, such as Xcode or Qt Creator.
- xenospn 2y agoI wonder if there are any other native IDEs with the same level of functionality. I feel like electron is forcing me to compromise on performance in exchange for features.
- yurishimo 2y agoWhat projects do you typically work on? I would say VS code only excels at JavaScript or perhaps newer languages with a robust LSP. What sort of features do you find most important from VS Code?
- xenospn 2y agoI work on full stack typescript applications. The most important features for me would be responsiveness (I usually have multiple projects open simultaneously, and performance tends to degrade after a few days) and memory consumption.
- tomphoolery 2y agocan we do this for react native? asking for a friend...
- traspler 2y agoIsn‘t that kind of the idea of Hermes?
- whizzter 2y agoI think all the sources are pre-parsed and compiled but it's not an outright snapshot as in nothing is executed ahead of time.
- whizzter 2y agoNot the same runtime, but iirc parsing,etc is done at an earlier stage in Hermes/RN so some parts of the initialization process is already done in that way if I'm not mistaken.
- Pepe1vo 2y agoIs there an advantage to doing this versus using something like ncc to just package everything into a single js file with zero dependencies?
- diggan 2y agoLet's say you're initializing a huge array on boot that takes 100ms. Packaging everything into a single .js file won't change that. Taking a snapshot of the state after boot and using that for subsequent boots will allow you to skip that.
- hardwaresofton 2y agoSurprised that vercel/ncc is still supported but vercel/pkg is not... Wonder why that is.
- butz 2y agoHow about making all installed Electron applications faster by using single shared runtime?
- diggan 2y agoCould work, except Electron changes very often. Electron is like 10 years old at this point, with 1,512 releases listed on GitHub, meaning 12 releases per month (151 releases per year). Only applications who use the same version would be able to actually take advantage of this, so not sure how big impact it would have. Instead, Tauri (Electron-like framework) does it like that by default, using whatever you have installed instead of shipping their own runtime. Might be interesting if you're looking for a sleeker version of Electron (but made with Rust instead of mostly C++ and TypeScript).
- antonkochubey 2y agoElectron could also figure out a way to change less often, like JVM does ;)
- half-kh-hacker 2y agoA lot of Electron applications in the Arch Linux package repositories use a system electron package, it's nice. They have to be split by major version, though.