How to speed up Timefold Solver Startup Time by 20x with native images

As more applications are moving towards cloud deployments, minimizing startup time is becoming more and more important. Read on to find out how to use Timefold Solver with Spring native images to reduce startup time in your application.

If you want to follow along, clone the Timefold quickstarts and change to the technology/java-spring-boot directory, which is already set up to support Spring native images:

git clone https://github.com/TimefoldAI/timefold-quickstarts.git
cd timefold-quickstarts/technology/java-spring-boot

# Setup

You can modify your existing Spring applications to support building Spring native images by modifying your configuration.

<build>
  <plugin>
      <groupId>org.graalvm.buildtools</groupId>
      <artifactId>native-maven-plugin</artifactId>
  </plugin>
</build>

plugins {
    // ...
    id 'org.graalvm.buildtools.native' version '0.10.1'
}

# Building

Spring provides two ways of building a native image:

• Using Docker
• Using a locally installed GraalVM

# Build using Docker

mvn -Pnative spring-boot:build-image

gradle bootBuildImage

This will produce an image tagged as docker.io/library/${name}:${version} where ${name} is the artifactId in Maven or the archivesBaseName in Gradle.

You can then run the image using Docker:

docker run --rm -p 8080:8080 docker.io/library/docker.io/library/timefold-solver-spring-boot-school-timetabling-quickstart:1.0-SNAPSHOT

# Build using locally installed GraalVM

mvn -Pnative native:compile

./target/timefold-solver-spring-boot-school-timetabling-quickstart

gradle nativeCompile

./build/native/nativeCompile/java-spring-boot

# Benefits

The primary benefit of native images is the massively reduced startup time:

./target/timefold-solver-spring-boot-school-timetabling-quickstart
...
20:40:44.888  INFO [main           ] Started TimetableSpringBootApp in 0.07 seconds (process running for 0.073)

Compared to running with a JVM:

java -jar target/timefold-solver-spring-boot-school-timetabling-quickstart-1.0-SNAPSHOT.jar
...
20:42:40.323  INFO [main           ] Started TimetableSpringBootApp in 1.216 seconds (process running for 1.426)

The native image started 20 times faster! This means a freshly started Kubernetes pod can respond to its first requests 20 times faster when a native image is used, changing an abysmal ~1 seconds wait time to a much more acceptable ~0.1 seconds wait time.

However, it is not all roses, since a native image is unable to perform various profiling based optimizations that a JVM can perform, reducing the speed of compute bound problems (such as solving):

./target/timefold-solver-spring-boot-school-timetabling-quickstart
...
20:58:43.064  INFO [pool-5-thread-1] Solving ended: ... score calculation speed (124774/sec) ...

Compared to running with a JVM:

java -jar target/timefold-solver-spring-boot-school-timetabling-quickstart-1.0-SNAPSHOT.jar
...
20:56:17.441  INFO [pool-2-thread-1] Solving ended: ... score calculation speed (213780/sec) ...

In a native image, Timefold Solver ran about 42% slower compared to a JVM run. This means to get to the same solution as a JVM run, the native image would need to run almost twice as long!

Important: Make sure to use GraalVM JDK 22 or above to generate the native image, which fixes a major performance regression involving record hashCode and equals.

# Conclusion

It is easy to modify your existing Spring applications to make use of native images, allowing you to massively reduce startup time and thus respond to requests quicker on newly spawned Kubernetes pods. However, using native images currently prevents profiling based JIT optimizations, significantly impacting performance for compute bound tasks such as solving. If you have long-running solving tasks, consider running the solver in a separate application, which will allow you to gain the startup time benefits without affecting the performance of the solver.