Reduce BeanDefinition cloning in AbstractBeanFactory.getMergedBeanDefinition [SPR-12236]

[spring-projects-issues]

Phil Webb opened SPR-12236 and commented

Profiling the Spring Boot Petclinic sample shows that the getMergedBeanDefinition method in AbstractBeanFactory is called 80,000+ times (and before configuration is frozen). The main callers are getType and getTypeMatch.

We could improve performance by not always cloning the BeanDefinition in this method.

---

Affects: 4.1 GA

Issue Links:

• markBeanAsCreated does not clear merged bean definition in a thread-safe fashion [SPR-14269] #18841 markBeanAsCreated does not clear merged bean definition in a thread-safe fashion
• Use already loaded metadata when possible for AbstractAutowireCapableBeanFactory.getTypeForFactoryMethod [SPR-13144] #17735 Use already loaded metadata when possible for AbstractAutowireCapableBeanFactory.getTypeForFactoryMethod
• Reduce memory consumption for caches [SPR-13093] #17684 Reduce memory consumption for caches

Referenced from: commits 09eb492

[spring-projects-issues]

Phil Webb commented

#820 helps a little with this

[spring-projects-issues]

Juergen Hoeller commented

I'm trying a slightly different approach now: allowing for early caching of merged bean definitions, enforcing a fresh re-cache step once a bean is about to be created (in order to catch the latest metadata modifications if any).

Juergen

[spring-projects-issues]

Juergen Hoeller commented

The re-caching approach seems to work fine in combination with a few extra measures, such as re-caching not only when a bean is about to be created but also after the ApplicationContext post-process phase. Some pre-resolved metadata is critical to retain afterwards though, e.g. for qualifier matching on factory methods, so we keep the merged bean definition around afterwards.

Juergen