Since its inception, Quarkus has been known for its fast startup times, whether running on the JVM or as a native image with GraalVM/Mandrel.
After years of optimizations to reduce startup costs, profiling JVM Quarkus applications startup today often shows the same recurring hotspots: class loading and reading from JAR files. This is not new to us, we already pushed these areas hard with custom packaging and class loading, but they remain a significant part of the startup profile.
Enter Project Leyden. It promises a major shift for the JVM with faster startup and lower warm-up costs, which looks like a match made in heaven for Quarkus. But it also raises important questions: how do we combine Leyden’s approach with Quarkus’ existing build-time and startup optimizations? Can we get the best of both worlds? In this talk, we share hands-on experience experimenting with Project Leyden from the perspective of Quarkus internals. We’ll look at what Leyden enables today, what it doesn’t yet, and how, at least in its current state, some of its limitations conflict with some of the optimizations Quarkus relies on, as well as how we hope to address this in the future.
Rather than a high-level overview, this session focuses on concrete findings: what worked, what surprised us, what broke, and what forced us to rethink parts of our design in order to preserve Quarkus’ performance while benefiting from Leyden. We’ll discuss performance characteristics, current limitations, crazy prototypes, and real-world optimization anecdotes.