4 ms·
> The 4 second application is a web server. They also give a basic example starting in 0.031s, fine for a CLI. Sure, my comment was more about the relative imp
by diggan 2y ago
> The 4 second application is a web server. They also give a basic example starting in 0.031s, fine for a CLI.
Sure, my comment was more about the relative improvement. In the case of the 0.031s example (which is the number without the improvement), it gets down to 0.018s with this new AOT class loading. What value do you get from something starting in 0.018s instead of 0.031s? The difference is so marginal for that particular use case.
> One of the use cases for startup time is AWS lambda and similar.
I suppose that's one use case where it does make sense to really focus on startup times. But again, I'd rather use something that fast startup already exists (Babashka, ClojureScript) instead of having to add yet another build-step into the process.
- kuschku 2y agoIf you're building e.g. a PS1 prompt replacement, you'll want to start, gather data, output the PS1 prompt and exit in less than 0.016s at most. Any slower and the user will see a visible delay. If you're on higher FPS monitors, the budget shrinks accordingly. At 60fps you'll have 16ms, at 480fps you'll have 2ms. The same applies for any app that should feel like it starts instantly.
- Tostino 2y agoThere are plenty of CLI applications that need to be low overhead. E.g. postgres can call a wal archive command for backup purposes, and I specifically remember work being done to reduce the startup overhead for backup tools like pgbackrest / wal-e.