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

Efficient type matching support for large number of beans [SPR-17528] #22060

Open
spring-projects-issues opened this issue Nov 21, 2018 · 0 comments
Assignees
Labels
in: core type: enhancement
Milestone

Comments

@spring-projects-issues
Copy link
Collaborator

@spring-projects-issues spring-projects-issues commented Nov 21, 2018

Rahul Shinde opened SPR-17528 and commented

During profiling the application, it was found that around 19% of time was spent in the various BeanFactory methods.
See JFR snapshot:

sbf_jfr_before.png

Our application has over 10K beans and around 3K beans loaded at startup (~10% of them during and remaining immediately after ApplicationContext refresh).
The current implementation of DefaultListableBeanFactory::doGetBeanNamesForType invokes AbstractBeanFactory::predictBeanType twice for every type lookup (one via isFactoryBean and the other during isTypeMatch)
As the doGetBeanNamesForType implementation iterates over all the available bean definitions, in our case, the number of calls to predictBeanType quickly escalate to 10K * 3K * 2 = 60M.

The existing cache inside of DefaultListableBeanFactory does help for subsequent lookups though.
I initially tried to minimize the number of calls to predictBeanType by adding a caching layer however the code in doGetBeanNamesForType seemed a bit hard to understand given the various corner cases it deals with.

sbf_code.png (107.01 kB)

It gave 10 seconds improvements however the lookup in the cache started showing up as the new hotspot.

Since the iteration over all the 10K bean definitions for every type lookup seemed to be the root cause, after several attempts, this is what I came up with (See PR).
The implementation goes over all the bean definitions and caches the type to name mapping once. It grabs the super types as well to avoid supplying a partial list of bean names in some cases.

Here is the JFR Hot Methods after applying the change:

sbf_jfr_after.png (89.60 kB)

This has helped speed up our application by around 25 seconds with no other change.
So far, it has been working fine for us on all our automated tests.
I would like to get your opinion on the change and if you think this would cause any long term breakages as Spring evolves.

Also it would be great if the core implementation itself can support more efficient lookups for types with sizeable beans in the registry.

 


Affects: 5.1 GA

Attachments:

Issue Links:

  • #17677 Autowiring with @Autowired/@Inject get much slower than with @Resource as the number of classes increases
  • #18188 Improve performance of #getBeanNamesForType() while the BeanFactory configuration is not yet frozen

Referenced from: pull request #2021

@spring-projects-issues spring-projects-issues added type: enhancement in: core labels Jan 11, 2019
@spring-projects-issues spring-projects-issues added this to the 5.2 RC1 milestone Jan 11, 2019
@jhoeller jhoeller removed this from the 5.2 M1 milestone Mar 4, 2019
@jhoeller jhoeller added this to the 5.2 M2 milestone Mar 4, 2019
@jhoeller jhoeller removed this from the 5.2 M2 milestone Apr 23, 2019
@jhoeller jhoeller added this to the 5.2 RC1 milestone Apr 23, 2019
@jhoeller jhoeller removed this from the 5.2 M3 milestone May 7, 2019
@jhoeller jhoeller added this to the 5.2 RC1 milestone May 7, 2019
@jhoeller jhoeller removed this from the 5.2 RC1 milestone Jul 10, 2019
@jhoeller jhoeller added this to the 5.2 RC2 milestone Jul 10, 2019
@jhoeller jhoeller removed this from the 5.2 RC2 milestone Sep 2, 2019
@jhoeller jhoeller added this to the 5.2 GA milestone Sep 2, 2019
@jhoeller jhoeller removed this from the 5.2 GA milestone Sep 23, 2019
@jhoeller jhoeller added this to the 5.3 M1 milestone Sep 23, 2019
@jhoeller jhoeller removed this from the 5.3 M1 milestone May 12, 2020
@jhoeller jhoeller added this to the 5.3 M2 milestone May 12, 2020
@jhoeller jhoeller removed this from the 5.3 M2 milestone Jun 23, 2020
@jhoeller jhoeller added this to the 5.3 RC1 milestone Jun 23, 2020
@jhoeller jhoeller removed this from the 5.3 RC1 milestone Aug 24, 2020
@jhoeller jhoeller added this to the 5.3 RC2 milestone Aug 24, 2020
@jhoeller jhoeller removed this from the 5.3 RC2 milestone Sep 14, 2020
@jhoeller jhoeller added this to the 5.x Backlog milestone Sep 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
in: core type: enhancement
Projects
None yet
Development

No branches or pull requests

2 participants