5 ms·

We had to dump a Clojure code base for Golang because it was too slow for lambda usage. Does any of this release help with startup time?

diggan 2y ago
> Does any of this release help with startup time? Clojure (and indirectly Java) was never created with "fast startup speed" in mind. This is why things like `add-lib` (that was added in this release) is so useful, because you start your developing session once, and it stays open until you either have to restart your computer or done developing the project. Then the typical deployment target is either "Push this .jar to a server somehow, start the process and let it run" or "User double-clicks executable, waits for application to be ready". If you really need fast startup, you can go through something like https://github.com/ionutbalosin/faster-jvm-start-up-techniques https://github.com/ionutbalosin/faster-jvm-start-up-techniqu... Or if you're fine with slightly worse runtime performance, give https://github.com/babashka/babashka https://github.com/babashka/babashka a try Finally, if you're OK with JavaScript you could give ClojureScript a try, has fast startup (as fast as NodeJS I suppose) but yeah, it's JavaScript. But overall, Clojure/Java isn't optimized for the use-case of "Start process for each request, stop process once processed" so I'm guessing you'll face an uphill battle there.
souenzzo 2y ago
No changes from clojure. But from java world: With GraalVM/NativeImage, it is possible to compile (clojure or java) .jar files into native binaries. Those binaries have a way faster to startup (less than 10ms for non-trivial apps) Also, lambda engines (like AWS lambda) continuously improve their "java" target, with preloading and other things,which also benefits clojure. TLDR; clojure startup isn't a thing that needs to be fixed. JVM startup used to be slow. And this is being resolved in the JVM itself. Note: clojure DEV startup time is still slow-ish. Clojure DEV is usually not AOT compiled and etc. the new "sync deps" feature helps to solve this DEV problem

diggan 2y ago

> Does any of this release help with startup time? Clojure (and indirectly Java) was never created with "fast startup speed" in mind. This is why things like `add-lib` (that was added in this release) is so useful, because you start your developing session once, and it stays open until you either have to restart your computer or done developing the project. Then the typical deployment target is either "Push this .jar to a server somehow, start the process and let it run" or "User double-clicks executable, waits for application to be ready". If you really need fast startup, you can go through something like https://github.com/ionutbalosin/faster-jvm-start-up-techniques https://github.com/ionutbalosin/faster-jvm-start-up-techniqu... Or if you're fine with slightly worse runtime performance, give https://github.com/babashka/babashka https://github.com/babashka/babashka a try Finally, if you're OK with JavaScript you could give ClojureScript a try, has fast startup (as fast as NodeJS I suppose) but yeah, it's JavaScript. But overall, Clojure/Java isn't optimized for the use-case of "Start process for each request, stop process once processed" so I'm guessing you'll face an uphill battle there.

souenzzo 2y ago

No changes from clojure. But from java world: With GraalVM/NativeImage, it is possible to compile (clojure or java) .jar files into native binaries. Those binaries have a way faster to startup (less than 10ms for non-trivial apps) Also, lambda engines (like AWS lambda) continuously improve their "java" target, with preloading and other things,which also benefits clojure. TLDR; clojure startup isn't a thing that needs to be fixed. JVM startup used to be slow. And this is being resolved in the JVM itself. Note: clojure DEV startup time is still slow-ish. Clojure DEV is usually not AOT compiled and etc. the new "sync deps" feature helps to solve this DEV problem