-
Notifications
You must be signed in to change notification settings - Fork 17
Benchmark CacheAutoConfiguration and work out how to optimize #5
Comments
Some more analysis breaks the 200ms down as follows (it includes transaction annotation processing as well):
The pointcut processing could maybe be optimized away using an index of some sort - it is all about checking all the methods of all the beans for annotations, and 99% of the time there was no point even looking. The cache initialization is native to JCache (or EhCache) but it can probably be deferred somehow, e.g. till the first time the cache is used. The rest is mysterious. Best guess so far is that it is the sheer number of cache provider configurations that have to be processed (there are 10). There are some suspicious sources of possible slowness in there (like a linear search for a provider in a map), but none of them seem to account for the whole 30ms. |
A different experiment, slight more granular breakdown:
which translates to
The "empty" sample has no caching. The "simple" sample is Spring Boot without JSR107 and manually selecting the cache type. The "cache" sample is the same, but with JSR107 on the classpath so Spring Framework adds some extra features. The "jcache" sample has EhCache as well and Spring Boot selects the cache provider. There are no |
There might be nothing we can do here, but you can see the effect on Petclinic (1800ms startup without caching, 2000ms with). Maybe scanning all beans for
@Cacheable
?The text was updated successfully, but these errors were encountered: