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.
Improving startup time in Atom with V8 snapshots
121–130 of 173 posts
Re: Improving startup time in Atom with V8 snapshots
#122Earlier quoted context omitted.
IntelliJ does a good job of it without resorting to Electron.
No, it just resorts to the freaking JVM , which is not any more lightweight or native than Electron apps.
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.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/
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.
Re: Improving startup time in Atom with V8 snapshots
#123Re: Improving startup time in Atom with V8 snapshots
#124I'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.
Re: Improving startup time in Atom with V8 snapshots
#125I'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…
What is cheaper, more memory or a SublimeText license?
Re: Improving startup time in Atom with V8 snapshots
#126I'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…
You could try lowering the "swappiness".
Re: Improving startup time in Atom with V8 snapshots
#127Earlier quoted context omitted.
See, I just don't understand why you would want to use emacs over an editor that does all the work for you. Thats why I avoid it, it seems like a big cost that I don't have to pay if I just use a different editor.
How do you think an IDE "does all the work" for you? Somebody working on the editor wrote some code in C++ or Java or whatever that makes it do that, and that code is baked into the IDE. In emacs, the only missing part is that perhaps nobody has already written the elisp that makes it do whatever task you are asking for. emacs is a smallish program written mostly in C that defers to a scripting language for nearly ev…
Thats exactly my point, theyve written all the various features you might have to write yourself, and theyve integrated them for you.
Re: Improving startup time in Atom with V8 snapshots
#128Earlier quoted context omitted.
I do actually, and I should reword that to "not useful for serious programming." VIM to me is best used for lightweight, quick and short editing tasks. THats how I use it. For any involved work, you're going to want a debugger, you're going to want automated build tools, you're going to want effortless compile/run cycles and so on.. You don't really want to implement all of that in VIM because your work won't be port…
I have all those. They're just not integrated into my editor. I use vim; it is my editor, but not my development environment. Unix is my development environment.
I;ve tried that approach, and its cumbersome to remember all the different commands, flags, combinations etc. I might need for each different project and for each different task. IDEs simplify this process dramatically. Its akin to GUI v DOS in terms of usability benefits.
Re: Improving startup time in Atom with V8 snapshots
#129Earlier quoted context omitted.
I have all those. They're just not integrated into my editor. I use vim; it is my editor, but not my development environment. Unix is my development environment.
I;ve tried that approach, and its cumbersome to remember all the different commands, flags, combinations etc. I might need for each different project and for each different task. IDEs simplify this process dramatically. Its akin to GUI v DOS in terms of usability benefits.
That's fine. But myself and a lot of other people get a lot of "serious programming" done using the approach.
Re: Improving startup time in Atom with V8 snapshots
#130Earlier quoted context omitted.
I;ve tried that approach, and its cumbersome to remember all the different commands, flags, combinations etc. I might need for each different project and for each different task. IDEs simplify this process dramatically. Its akin to GUI v DOS in terms of usability benefits.
That's fine. But myself and a lot of other people get a lot of "serious programming" done using the approach.
I don't really understand what the benefit of it is.