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.
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
@EnableAutoConfigurationis 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.