-
Notifications
You must be signed in to change notification settings - Fork 40.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Optimize startup time: condition processing #7573
Comments
Another option that we've discussed before is to somehow pre-determine |
See also #7939 |
Some experimental code is here. Running petclinic locally in the IDE with 1.5.0.RC1
And with the experimental branch (including the other optimizations we've already pushed)
|
And with a hacked version of the benchmarks to support 1.5.0
|
RC1 comparisons:
|
Also worth nothing that the filtering code runs in the following time:
After that's run it's pretty much as if those auto-configuration classes were never there. |
There's one flaw with the current implementation. We need to store |
The experimental code that fills in the outcomes isn't thread-safe. There's no guarantee that outcomes filled in by the background thread will be visible to the main thread. Using an |
@wilkinsona Thanks Andy! I've pushed updated code here. It should fix that and the ordering issue. |
I don't see such dramatic improvements in the benchmark times, but my hardware is faster, so maybe the difference is minimized, or maybe the thread safety had an impact.
|
@dsyer Guess I need an upgrade, you're about 3 seconds faster than me to begin with! What hardware are you using? |
Update `OnClassCondition` to use its own `isPresent` rather than using `ClassUtils.isPresent`. Using our own implementation saves a few cycles since we never need to check for native types, and we don't support nested class references specified in the non `$` notation. See spring-projectsgh-7573
Update `OnBeanCondition` to no longer call `ReflectionUtils` when deducing the bean method return type. Since Spring Framework 4.2 the return type has been directly available from `MethodMetadata`. See spring-projectsgh-7573
Update `AutoConfigurationImportSelector` so that exclude properties are loaded without invoking a `DataBinder`. This optimization helps to improve application startup time. See spring-projectsgh-7573
Optimize OnEnabledResourceChainCondition by removing the DataBinder. Properties are now read directly from the Environment. See spring-projectsgh-7573
Add an annotation processor that generates properties files for certain auto-configuration class annotations. Currently attribute values from @AutoConfigureOrder, @AutoConfigureBefore, @AutoConfigureAfter and @ConditionalOnClass annotations are stored. The properties file will allow optimizations to be added in the `spring-boot-autoconfigure` project. Primarily by removing the need to ASM parse as many `.class` files. See spring-projectsgh-7573
Add AutoConfigurationMetadata interface and a an internal loader that allows easy access to data written by `spring-boot-configure-processor`. See spring-projectsgh-7573
Optimize `AutoConfigurationSorter` by used properties generated by the annotation processor whenever possible. The removes the need for each candidate class to be ASM parsed just to access the order annotations. See spring-projectsgh-7573
Add `AutoConfigurationImportFilter` strategy interface which can be used to filter auto-configuration candidates before they are loaded. See spring-projectsgh-7573
Update OnClassCondition to implement AutoConfigurationImportFilter so that auto-configuration candidates can be filtered early. The optimization helps to improve application startup time by reducing the number of classes that are loaded. See spring-projectsgh-7573
Add an annotation processor that generates properties files for certain auto-configuration class annotations. Currently attribute values from @AutoConfigureOrder, @AutoConfigureBefore, @AutoConfigureAfter and @ConditionalOnClass annotations are stored. The properties file will allow optimizations to be added in the `spring-boot-autoconfigure` project. Primarily by removing the need to ASM parse as many `.class` files. See gh-7573
Add AutoConfigurationMetadata interface and a an internal loader that allows easy access to data written by `spring-boot-configure-processor`. See gh-7573
Optimize `AutoConfigurationSorter` by used properties generated by the annotation processor whenever possible. The removes the need for each candidate class to be ASM parsed just to access the order annotations. See gh-7573
Add `AutoConfigurationImportFilter` strategy interface which can be used to filter auto-configuration candidates before they are loaded. See gh-7573
Update OnClassCondition to implement AutoConfigurationImportFilter so that auto-configuration candidates can be filtered early. The optimization helps to improve application startup time by reducing the number of classes that are loaded. See gh-7573
Latest timings for me:
|
I think this is going to be about as good as it gets for the 1.x line. We should do some more profiling towards the end of 2.0 |
I updated the benchmarks with new tests for Spring Boot 1.5. There are a few improvements in Spring Boot 1.5 that affect startup time
The configserver benefits by a few hundred millseconds. The vanilla |
Benchmark data from here https://github.com/dsyer/spring-boot-startup-bench suggest that condition processing is noticeable at startup time (not dominating it, but it's non-negligible, amounting to a few hundred ms depending on hardware). The most startling evidence is the "minimal" sample app from that project where
@EnableAutoConfiguration
is disabled and startup time improves dramatically.One way this could maybe be fixed is to break up spring-boot-autoconfigure into separate modules, so that only the conditions you need to be evaluated will be, for any given app, based on the classpath.
The text was updated successfully, but these errors were encountered: