When running from Maven or Gradle (e.g. mvn spring-boot:run), if we know that devtools is going to be used, there might be some things we can do to improve startup times:
-XX:TieredStopAtLevel=1 has a big effect-noverify also has an appreciable effect- Run the main method, not the jar launcher (if we don't already)
Devtools restarts are already pretty fast, but the initial launch could be quicker. There are also some tricks you can play with -Xshare:on to use pre-parsed class data cached on disk. There might be other things (@aclement is a font of ideas).
See #7493 for some discussion and benchmarks (also https://github.com/dsyer/spring-boot-startup-bench).
N.B. we don't recommend running from the command line if you have an IDE, so maybe it would be better to concentrate on that (spring-attic/spring-ide#85). Users can definitely set default JVM flags in the IDE already, so we would only be doing something that they could do themselves if they knew about it.
When running from Maven or Gradle (e.g.
mvn spring-boot:run), if we know that devtools is going to be used, there might be some things we can do to improve startup times:-XX:TieredStopAtLevel=1has a big effect-noverifyalso has an appreciable effectDevtools restarts are already pretty fast, but the initial launch could be quicker. There are also some tricks you can play with
-Xshare:onto use pre-parsed class data cached on disk. There might be other things (@aclement is a font of ideas).See #7493 for some discussion and benchmarks (also https://github.com/dsyer/spring-boot-startup-bench).
N.B. we don't recommend running from the command line if you have an IDE, so maybe it would be better to concentrate on that (spring-attic/spring-ide#85). Users can definitely set default JVM flags in the IDE already, so we would only be doing something that they could do themselves if they knew about it.