Lazy cache provider initialization [SPR-17646]

[spring-projects-issues]

Dave Syer opened SPR-17646 and commented

Several opportunities:

• Pointcut processing is expensive, and involves reflecting on all methods of all beans. Clearly this doesn't scale well and could be indexed away. Could also be used with @Transactional (and @Secured etc.).
• The cache provider (e.g. EhCache) has expensive internal initialization. This could perhaps be deferred until the cache is actually used.
• Some other stuff in Spring Boot might help (condition evaluation and import selection)

Some analysis and benchmarks here: spring-projects-experimental/spring-init#5

---

Affects: 5.1.3

Reference URL: spring-projects-experimental/spring-init#5

[spring-projects-issues]

Stéphane Nicoll commented

The cache provider (e.g. EhCache) has expensive internal initialization. This could perhaps be deferred until the cache is actually used.

Just a note that several things may go wrong (configuration file not found, configuration invalid, network topology that has to be validated on startup) so whatever we do here should be opt-in. It would be nice though if we wouldn't have to do that for every single component that we optimize this way

[snicoll]

Some additional data point here https://github.com/scratches/spring-cache-bench

[jhoeller]

For a start, #22420 covers the pointcut processing part: We are not traversing classes now if they are known to not declare the desired annotation type. This is implemented for our async, caching, and transaction annotations, ignoring java* classes by default but also participating in the single unified hook (AnnotationUtils.isCandidateClass) which we have for our upcoming indexer integration.