4 ms·

The 4 second application is a web server. They also give a basic example starting in 0.031s, fine for a CLI. One of the use cases for startup time is AWS lambd

by dtech 2y ago

The 4 second application is a web server. They also give a basic example starting in 0.031s, fine for a CLI. One of the use cases for startup time is AWS lambda and similar.

bobnamob 2y ago
Prebuilding a cache through a training run will be difficult between lambda invocations though and snapstart[1] already "solves" a lot of the issues a class cache might address. [1] https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html Of course, I wouldn't be surprised if the boffins at lambda add some integration between snapstart and class caching once their leadership can get it funded
- fulafel 2y ago
  There are all kinds of spot solutions for (Babashka, vm snapshots like snapstart, graal, using clojurescript instead of clojure) but it would still be very nice to just get a speedup running vanilla JVM Clojure out of the box without fiddlery. Eg SnapStart only works on AWS, not on other FaaS platforms, even there needs extra cloud infra fiddlery and costs extra.
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 ago
  If 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 ago
  There 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.
jamesfinlayson 2y ago
> One of the use cases for startup time is AWS lambda and similar. Agreed - I've got some JVM Lambdas that are quite slow to start (it doesn't take many libraries to make a heavy Lambda). Someone else mentioned SnapStart which I think came out this year but there are enough caveats that I'm reluctant to try it in anger (big inherited code base that has shoved way too much into Lambda).

by dtech 2y ago

The 4 second application is a web server. They also give a basic example starting in 0.031s, fine for a CLI. One of the use cases for startup time is AWS lambda and similar.

bobnamob 2y ago

Prebuilding a cache through a training run will be difficult between lambda invocations though and snapstart[1] already "solves" a lot of the issues a class cache might address. [1] https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html https://docs.aws.amazon.com/lambda/latest/dg/snapstart.html Of course, I wouldn't be surprised if the boffins at lambda add some integration between snapstart and class caching once their leadership can get it funded

fulafel 2y ago
There are all kinds of spot solutions for (Babashka, vm snapshots like snapstart, graal, using clojurescript instead of clojure) but it would still be very nice to just get a speedup running vanilla JVM Clojure out of the box without fiddlery. Eg SnapStart only works on AWS, not on other FaaS platforms, even there needs extra cloud infra fiddlery and costs extra.

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 ago
If 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 ago
There 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.

jamesfinlayson 2y ago

> One of the use cases for startup time is AWS lambda and similar. Agreed - I've got some JVM Lambdas that are quite slow to start (it doesn't take many libraries to make a heavy Lambda). Someone else mentioned SnapStart which I think came out this year but there are enough caveats that I'm reluctant to try it in anger (big inherited code base that has shoved way too much into Lambda).