Startup performance with devtools

[dsyer]

There might be some things we can do to improve startup times:

• -XX:TieredStopAtLevel=1 has a big effect
• -noverify also is appreciable
• 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 spring-projects/spring-boot#7493 for some discussion and benchmarks (also https://github.com/dsyer/spring-boot-startup-bench).

[spring-projects-issues]

(comment in Pivotal Tracker added by Andy Clement:)

Not sure this should be squeezed into 3.8.3 - need to think it through more. Xshare requires turning on JVM for commercial use and I don't think we want to 'just do that' under the covers.

[spring-projects-issues]

(comment in Pivotal Tracker added by Martin Lippert:)

Maybe we could add the low-hanging and low-risk changes to the 3.8.3 release and look at the more complicated ones (-Xshare) for 3.8.4.
Low hanging candidates:
-noverify
-XX:TieredStopAtLevel=1

[dsyer]

Those low hanging ones are pretty easy for users to do themselves, but if we do it, they will have a better experience without knowing the details. So that sounds like a good first step.

[spring-projects-issues]

(comment in Pivotal Tracker added by Andy Clement:)

The only downside is that they do have an impact and the user won't be aware of the choice that is being made for them.

-noverify is probably fine. (do we start STS with noverify to speed it up - can't recall if we added that but I know we had an item for it somewhere).

-XX:TieredStopAtLevel=1 - is saying "I want it to start fast, in return I don't mind if it isn't going at maximum speed later because I'm not going to be running this for long".

I guess I'm thinking of a little transparency, first launch ask them the question if they want to use it and briefly indicate the trade offs, then persist that decision.

[spring-projects-issues]

(comment in Pivotal Tracker added by Andy Clement:)

Per my last comment. I think those are the two to run with. But I don't want to do them silently, the developer should be able to opt-in the first time they do something that might benefit from them. (together with a dont-ask-me-again option). For someone who answers no/dont-ask-me-again to whatever we initially ask a small checkbox or something to do it in the launch config box might be nice.

[spring-projects-issues]

(comment in Pivotal Tracker added by Kris De Volder:)

The two options -noverify and -XX:TieredStopAtLevel=1 seems independent from devtools. So we could add them on any launch without checking if they have devtools as a dependency... correct?

[spring-projects-issues]

(comment in Pivotal Tracker added by Andy Clement:)

Yes they are independent.

[spring-projects-issues]

(comment in Pivotal Tracker added by Alex Boyko:)

Are we adding this to Boot launch? I'm thinking about looking into implementing it...

[spring-projects-issues]

(comment in Pivotal Tracker added by Martin Lippert:)

I think we can add this, but should offer a clear preference page for it. That preferences page would allow the user to disable this "automatic addition to JVM options" and would allow the user the specify those automatic JVM options (with "Restore Defaults" to get back to our preferred settings).