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).