Skip to content
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 constructor dependency injection performance for parameter name matches #28122

Closed
alaneuler opened this issue Mar 2, 2022 · 4 comments
Assignees
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Milestone

Comments

@alaneuler
Copy link

alaneuler commented Mar 2, 2022

If initializing bean via constructor dependency injection, Spring will do the candidates look-up by parameter type (essentially via BeanFactoryUtils#beanNamesForTypeIncludingAncestors) which is really slow if application getting huge. We are searching an approach to tell Spring to look-up candidates by constructor's parameter name.

I've read the code in ConstructorResolver but cannot find a way to achieve constructor dependency injection by parameter name. By the way there is a similar question on Stack Overflow: Spring autowire by name constructor arguments, there is just a work-around but not solution.

Can Spring support this feature if parameter name is available in runtime?

Affects: <All Spring Framework versions>

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged or decided on label Mar 2, 2022
@snicoll snicoll changed the title Support constructor dependency injection by parameter name. Support constructor dependency injection by parameter name Mar 2, 2022
@sbrannen sbrannen added the in: core Issues in core modules (aop, beans, core, context, expression) label Mar 2, 2022
@HzjNeverStop

This comment was marked as off-topic.

@snicoll

This comment was marked as resolved.

@snicoll snicoll self-assigned this Nov 27, 2023
@snicoll
Copy link
Member

snicoll commented Nov 27, 2023

I can see how getting bean name lookup could be interesting in some cases. We do have support for @Resource setter injection that has by-name semantic but we don't support this elsewhere. Perhaps a parameter name on the injection point could be an escape hatch for those who want to rely on this.

@jhoeller let's make up our mind on this?

@jhoeller jhoeller changed the title Support constructor dependency injection by parameter name Optimize constructor dependency injection performance for parameter name matches Dec 18, 2023
@jhoeller jhoeller added type: enhancement A general enhancement and removed status: waiting-for-triage An issue we've not yet triaged or decided on labels Dec 18, 2023
@jhoeller jhoeller self-assigned this Dec 18, 2023
@jhoeller jhoeller added this to the 6.2.x milestone Dec 18, 2023
@jhoeller jhoeller modified the milestones: 6.2.x, 6.2.0-M1 Feb 5, 2024
@jhoeller
Copy link
Contributor

In a micro-benchmark with 3000 bean definitions with distinct bean classes and 3000 injection points requesting each of those beans, this new shortcut for parameter names matching the target bean names led to ~10x better autowiring performance. These assumptions will never consistently apply to real-life scenarios, but even for a fraction of the beans involved, the performance benefit should be noticeable.

Common parameter names and bean names are expected to match the convention already. Application setups can be explicitly designed for better autowiring performance through choosing consistent parameter names that match the target bean names, or alternatively through assigning aliases to the target beans that match the common parameter names declared in the application.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core Issues in core modules (aop, beans, core, context, expression) type: enhancement A general enhancement
Projects
None yet
Development

No branches or pull requests

6 participants