Autowiring performance degradation due to 5.2's MethodParameter.getParameterType() implementation

[e-hubert-opti]

Our applications makes considerable use of programmatic autowiring of beans via org.springframework.beans.factory.config.AutowireCapableBeanFactory#autowire.

Therefore we have a couple of performance tests, which directly and indirectly measure the throughput of the underlying Spring implementation.
All those tests degraded by about 20 to 25 percent, after only updating the Spring dependencies from version 5.1.9 to version 5.2.0.

We did a bit of work to pinpoint the changes in Spring, which resulted in this performance drop and thought it would be a good idea to report it here so you can verify, whether you like to accept this or have an idea how to achieve both, improved code robustness while maintaining performance.

The root of the actual performance degradation seems to originate from changes to org.springframework.core.MethodParameter#getParameterType to use org.springframework.core.ResolvableType (in our case itself used from org.springframework.beans.factory.support.ConstructorResolver#resolveAutowiredArgument).

The relevant issue motivating this change seems to be #23385

I quickly verified that it is enough to use 5.1.9 as base and only change the above mentioned two core classes, to observe the performance drop. I have not yet checked the Spring project for own performance tests.

[lgxbslgx]

I submit a PR to improve the performance of the method MethodParameter.getParameterType. Hope it could help.

[quaff]

I have the same issue. my web application built with both struts2 and spring mvc, after upgrade to spring 5.2.0, throughput of struts2 decrease to about 80%, but throughput of spring mvc is increased. struts2 action is autowired by AutowireCapableBeanFactory::createBean(clazz, AUTOWIRE_BY_NAME, false) .

BTW: @lgxbslgx's PR not helps much.

[quaff]

@e-hubert can you provide a simple project and try the PR #23811 ?

[e-hubert-opti]

@quaff I was looking at the PR and verified that it improved performace quite considerable for our use, but was still waiting for @jhoeller or one of the Spring core dev team members to likely come up with a different take on this.
I do not have a simple project at hand, but as the issue seems to be so isolated one might be better off with a parameterized microbenchmark (e.g. using JMH).

[jhoeller]

According to my local benchmarks, it seems sufficient to restore a containingClass != null check as we effectively had it in the 5.1.x code path. Refining it with a check for containingClass != declaringClass does not hurt but seems like an optimization beyond 5.1.x already, nevertheless worth it. I'll double-check the effect and will proceed with that change for inclusion in 5.2.1.

[e-hubert-opti]

If timing permits, I'm of course also willing to give a snapshot build of spring-core 5.2.1 containing the fix (once available) a try and check out all our performance test suites which showed regressions after our update attempt to 5.2.0, although I'm convinced that Jürgen's local micro benchmark is absolutely sufficient here. Thanks for addressing this!

[jhoeller]

A variant of this is in master now for inclusion in the upcoming 5.2.1 build snapshot. Please do try it tomorrow if you can since it's your scenario that actually matters, not my local little benchmark ;-)

[quaff]

I confirm commit dc59e50 works.

[e-hubert-opti]

I can confirm the issue to be fixed as well. I tested with spring-core-5.2.1.BUILD-20191030.000554-48.jar containing this change. Thanks again!