This is a follow up to our last post about Spring’s cache abstraction.
As engineers, you gain valuable experience by understanding the internals of some of the tools that you use. Understanding the behaviour of tools helps you become more mature when making design choices. In this post, we describe a benchmarking experiment and the results which will help you understand Spring’s built-in annotations for caching.
Take a look at the following two methods:
Here we have two very similar methods, each annotated with the built-in @Cacheable annotation from Spring Cache. The first one includes an expression written in the Spring Expression Language. The expression is used to configure how to calculate cache key using method parameters. The second one relies on Spring’s default behaviour which is “all method parameters are considered as a key”. Effectively, both the methods above actually result in exactly the same external behaviour.
We ran some benchmark tests, that allowed us to measure their performance:
It turns out that the method which had a manually configured cache runs 4.4 times slower! In hindsight, this outcome seems to make sense because of overheads. The Spring framework has to parse an arbitrarily complex expression and some cycles are consumed in this computation.
Why are we writing this story? Well –
- We care deeply about software performance.
- Our own codebase has a few of these instances where we have had to trade-off performance for zero benefits.
You should examine your code base and conduct a review or audit too. Jettison some of these instances as well and gain performance improvements. You could very well have some instances where you have manually configured cache keys as well. Remember, this is exactly the same behaviour that Spring Cache would provide you by default. A definite win-win situation!