OnClassCondition tries to determine the outcome for single auto-configuration classes in parallel

[dreis2211]

Hi,

I just noticed that a vanilla Spring-Boot app (with web, security and actuator starters) creates 200+ threads on startup. After a small investigation those threads turned out to be created by OnClassCondition. I noticed that threads are created even though the passed autoConfigurationClasses array has a length of 1. (Only one invocation in the lifetime of the app has multiple classes passed). In those cases it seems to be wasteful to create threads because the work cannot be split in half, really.

A small benchmark shows the following results:

	Baseline	New
	2.783	2.570
	2.811	2.562
	2.760	2.690
	2.707	2.704
	2.732	2.576
	2.646	2.659
	2.816	2.803
	2.847	2.578
	2.765	2.670
	2.722	2.731
Mean	2.759	2.654
Range	0.201	0.241

Let me know what you think.
Cheers,
Christoph

[wilkinsona]

Nice find, @dreis2211! Thank you.

The behaviour you've observed is a regression in Spring Boot 2.3. In 2.2 the filtering is only performed once for all of the auto-configuration classes. In 2.3, it's performed for all of the auto-configuration classes but then, as you have observed, it's performed many more times a single auto-configuration class at a time. I haven't yet had a chance to figure out why that is, but there may be an even bigger improvement to be found that restores 2.2's behaviour.

[wilkinsona]

6921fda introduced the change in behaviour. That was a good change to make. What you have proposed will just make it better. Thanks again.

[dreis2211]

I found this commit as well and didn't consider it a regression. Thanks for keeping me in the loop.

[wilkinsona]

@dreis2211 While you were working on this, I'm curious if you tried avoiding the creation of the StandardOutcomeResolver where there's only a single auto-configuration class involved? I'll give it a go if you haven't already tried it. I'm not sure it'll make a noticeable difference, but I think it's worth checking.

[dreis2211]

@wilkinsona I haven't because that seemed like it wouldn't be worth the effort. But feel free to give it a try.

[wilkinsona]

Thanks again, @dreis2211. I've yet to try avoiding creating the StandardOutcomeResolver. We're planning some more performance work during 2.4's development so we'll look at it then if needed.

[dreis2211]

Thanks @wilkinsona . Let me know if I can help with the performance work in any way.