Does implementing caching for non-db operations make sense? Does it make sense to implement it for evaluation of a lengthy block of code? For example, I have a block of code that takes in a parameter. Based on this param, it goes over a laundry list of if/else blocks until it matches the correct value and returns back a value. In my case, the IN param is finite and the OUT param is consistent based on IN Param i.e. for every 'A' the return is 'B' and for every 'X' the return is 'Z'. This kind of operation does not involve DB records. I am wondering by introducing caching, i can cut down any time from the evaluation over a long run. Suggestions? Thanks.
2 Answers
As long as the executed code is lengthy or complex enough so that it justifies the effort, this makes perfect sense. See for example Spring's caching annotation support at http://static.springsource.org/spring/docs/3.1.0.M1/spring-framework-reference/html/cache.html , which works on Java method level. But you can easily implement such an approach yourself in a non-Spring environment.
You should profile your application first to see how much time/CPU is spent in the affected code block to see if caching makes sense here.
Comments
It depends how you value low latency. According to this presentation from Google (slide #13), 1 MB of sequential read from the main memory costs about 0.25 ms, and there are plenty of other things which are more expensive. From the same slide:
- a single disk seek is 40 times slower;
- reading 1 MB of data from network is 40 times slower;
- reading 1 MB data from disk is 120 times slower
So caching can help tremendously in certain situations, but you need to do analysis and see how much time is your algorithm wasting and then decide.
