Application startup time is the interval between launch and readiness to handle requests. It matters when Kubernetes restarts an application or a serverless platform starts an instance after scaling down. With scale to zero, no instance is running until a request arrives; startup time then adds to that first request’s handling time. section 2.5 section 11.5.1
Quarkus reduces work at startup by moving tasks such as class loading, annotation scanning, and configuration processing to the build. Their results can be recorded and used when the application runs. A GraalVM native image also runs as a standalone executable without waiting for a JVM to start. section 2.5 section 1.2.2
Compare two launch logs
In one Quarkus 3.15.1 example, the runnable JAR reports “started in 0.397s,” while the native executable reports “started in 0.009s.” These are startup figures from the shown runs, not a promise that every application will reach those times. section 2.5
Choose the deployment form for the job. Native compilation is attractive when startup time is critical, particularly for serverless applications. A JVM deployment may better suit a service optimizing throughput. Native-image creation can require configuration and tuning, although Quarkus supplies much of the needed configuration and supports switching build output with a build-time flag. section 1.2.2 section 11.5.1
