From the outset Quarkus has been designed around a container first philosophy. What this means in real terms is that Quarkus is optimised for low memory usage and fast startup times in the following ways:
- First Class Support for Graal/SubstrateVM
Substrate support has been an important part of the design for Quarkus from the beginning. When an application is compiled down to a native image it starts much faster and can run with a much smaller heap than a standard JVM. Quarkus are all tested in Substrate, and can run without the
- Build Time Metadata Processing
As much processing as possible is done at build time, so your application will only contain the classes that are actually needed at runtime. In a traditional model all the classes required to perform the initial application deployment hang around for the life of the application, even though they are only used once. With Quarkus they are not even loaded into the production JVM. This results in less memory usage, and also faster startup time as all metadata processing has already been done.
As much as possible Quarkus tries to avoid reflection, reducing startup time and memory usage.
- Native Image Pre Boot
When running in a native image Quarkus pre-boots as much of the framework as possible during the native image build process. This means that the resulting native image has already run most of the startup code and serialized the result into the executable, resulting in even faster startup.