Hacker News Reader

Comment by fulafel | Hacker News Reader

What does this mean for Clojure? At least loading the Clojure runtime should benefit, but what about app code loading.

I feel like for the Clojure applications where you need it to start really fast, like tiny CLI utilities that don't do a lot of work, the improvements would be so marginal to not matter much. The example they use in the JEP seems to have gone from a ~4 second startup to ~2 seconds, which for a tiny CLI, still would make it seem pretty slow. You're better off trying to use Babashka, ClojureScript or any of the other solutions that give a fast startup.

And for the bigger applications (like web services and alike), you don't really care that it takes 5 seconds or 10 seconds to start it, you only restart the server during deployment anyways, so why would startup time matter so much?

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.

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

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

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.

> 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.

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.

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.

> 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).

Big apps where startup time matters are desktop/mobile GUI apps. These aren't heavily emphasized in the Clojure community (excluding ClojureScript), but they are feasible to build - and I do build some of them. If startup time is reduced by 40%, the end user will definitely notice it.

IMHO, while optimizations in the JVM are always welcome, they primarily address surface-level issues and don't tackle Clojure's core limitation: the lack of a proper tree shaker that understands Clojure semantics. Graalvm offers help here by doing whole-program optimization at the bytecode level, but a Clojure-specific tree shaker could take things further: it could eliminate unused vars before/during Clojure AOT, thereby reducing both program size and startup time. These improvements would happen before the JVM optimizations kick in, making everything that follows a nice extra bonus.

Interesting thought, I wonder if there's a way to reason about the magnitude of effect this would have.

Clojure and the JVM are so dynamic its hard to infer what namespaces/vars/classes might be needed during runtime. That makes static analysis like tree-shaking difficult. Whose to say some strings are concatenated together at runtime and used to load a namespace that might have been tree-shaken out? The only way to really know is to run the program.

IMHO, it doesn't need to be overly complicated, but I might be wrong. The optimizer doesn't have to optimize all the Clojure code out there (for the start). Still, it could adopt a Graalvm-like approach, explicitly stating which elements the optimizer can optimize and encouraging developers to write their code accordingly. Alternatively, it can go with CL "declare"-like construct [1], allowing developers to explicitly insert hints for the optimizer.

[1] https://www.lispworks.com/documentation/HyperSpec/Body/s_dec...

Load balanced web services on e.g. K8S could need to start and stop quite a lot if load varies. Any speed up will be welcome.

Also, I guess Java-based desktop applications like IntelliJ and DBeaver will benefit.

Very much so - I have a Java application running in Elastic Container Service that takes 35s-40s to start (it's not that heavy but it's running on limited hardware for cost reasons). Any improvement without needing to throw more hardware at it would be very welcome.

I don't know how this JEP affects Clojure, but if you want to use Clojure for fast-loading CLI apps, a good thing to look at is babashka (bb). I wrote about it here:

"Learning about babashka (bb), a minimalist Clojure for building CLI tools"

https://amontalenti.com/2020/07/11/babashka

It should benefit, if namespaces are AOT-compiled by Clojure.

Reply on news.ycombinator.com