The illustrations of this section show the startup time and heap usage after GC of a Quarkus app with RESTEasy and a Spring Boot Web app. Both apps expose one simple endpoint. JDK 1.8.0_201 was used to perform the tests.

Startup time & memory footprint

In this example, Quarkus is 2 times faster to start and consumes half the heap size used by Spring.

Because part of the initialization is done at build time, Quarkus has a reduced startup time.

The small memory footprint of Quarkus results from the fact that the application will only contain the classes that are actually needed at runtime.

Time to first request

To measure more accurately how long a framework needs to start, I wrote a simple node.js script to calculate the first response time to API requests after starting up Quarkus and Spring Boot. I shared it the following github repository.

I launched the script 5 times with a Quarkus runnable jar and the same times with a Spring Boot uber jar (the same jars used in the previous section).

The results were in accordance with the previously reported startup times.

On average, Quarkus took 1862 milliseconds to respond to the first request, while Spring Boot took 3580 milliseconds.

You can checkout the following article for a more in depth performance comparison in a real use case.

GraalVM native performance

Quarkus is an order of magnitude faster to start when packaged as a GraalVM native image and uses a much smaller heap.

This article can give you an idea of the startup time and memory footprint of frameworks that support native images such as Quarkus, Micronaut and Helidon.