Has Clojure startup time gotten way way better without me noticing? With Java 26 on my MacBook Air M4, I get Hello World in 0.2 seconds.
Project Leyden I'm guessing? https://openjdk.org/projects/leyden/
hmm I thought the Leyden changes were still options you had to configure explicitly?
Leyden includes aot type stuff requiring configuration and warm up runs, but also has influenced things in general startup
if i had to guess - if 26 was a turning point, making final fields be by-default trusted as final might have helped. That or the memory improvements. π€·
I doubt that final thing would affect startup time much. much more likely things like compressed object headers, fine-tuning of jdk loading etc
Maybe @chris441 has some insights into that. His talk for Clojure/Conj sounds like it would have some explanations and solid plans for the future: > Clojure succeeded by delivering a profoundly simple computing model that changed how we manage state and complexity. Yet, over the last fifteen years, both our real-world production experience and the underlying JVM have evolved dramatically. This talk explores how we can leverage modern JVM capabilities to advance Clojure's core abstractions without compromising its core philosophy. We share concrete research improvements to core language features, including a provably better protocol implementation and a novel compiler approach to vars that yields major startup performance gains. From this foundation, we make a call for deeper research into a modernized compiler and runtime.
> including a provably better protocol implementation and a novel compiler approach to vars that yields major startup performance gains. I'm interested in this
@chris441 give me spoilers
@emccue, @adam.kalisz - The talk is about https://cnuernber.github.io/ham-fisted/ham-fisted.defprotocol.html - the way we came about the ideas in there initially was via research (2023) into clojure startup times which yielded my https://github.com/cnuernber/clojure/tree/lazy-vars of clojure which proved the potential but isn't backwards compatible and isn't meant for any sort of production use. I do think there is plenty of space for real research into making clojure more efficient on the JVM but it isn't possible to go too far that direction in a backwards compatible way so it isn't something currently I have time to pursue and isn't something that I think anyone else is interested in pursuing. A research branch of clojure that is built on top of tools.analyzer and is much more minimal would be a cool starting point then at least you could do the research in Clojure and not Java.
Well, with compute and memory being way more expensive now, perhaps some changes may have a good ROI, especially considering that the JVM ecosystem made big leaps since Clojure was released almost 20 years ago. What would you need to be able to pursue this seriously?
Let's wait for the talk and discuss it then brother π. Our contracts and my two young children are my concern at the moment.
From Codex. Wow, Java 27 reduced execution (startup) time by 30%. > Yes. I measured about 0.28 seconds on your M2, without a custom AOT cache. The reported 0.2 seconds on an M4 is plausible, though we have not reproduced that exact hardware or time. > > Using Clojure 1.12.4 and (println βHello Worldβ): > > Installed Java Direct JVM launch clojure CLI > 21 0.380 s 0.388 s > 26.0.2 0.280 s 0.287 s > 27 0.273 s 0.274 s