Micro-Benchmarks can be used in addition to a profiler to find and fix problematic parts of your code. So, you can run a profiler to identify the problematic regions and then test those specific regions with micro-benchmarks.
Generally speaking, micro-benchmark frameworks (such as Caliper and JMH) are designed to prevent many of the common mistakes and make it easier to create meaningful benchmarks (as is described in the answer to this question). These are in many cases problems which don't occur in the same form when you're testing larger pieces of code; therefore it makes sense to keep micro-benchmarks small. (That's why they're called micro-benchmarks after all.)
Some things I've come up with are the following.
- if you've found a bottleneck and you may have a better solution
- if you're comparing several technologies which can do the same job (e.g. xml parsers) and want to know which one is fastest before using them in your real code
- if you have nothing else to improve about your code
- if the code has time wise unreliable outside dependencies (e.g. it talks over a network)
- if the measured piece of code won't be called very often (or if you're unsure) unless your application is REALLY time sensitive.
(= If you rarely run a piece of code, don't try optimize it. It probably won't be worth the time.)
- if the operation will take longer than a few milliseconds to complete
- just because your boss, manager or someone else who is in charge thinks that it's a good idea to do so
Also, while some people run micro-benchmarks regularly (as you would run unit tests), since I use them only to analyze problems I already know about (thanks to the profiler), these benchmarks are not something I'll need to run very often. There may be situations in which this would make sense (and if you know of one, please comment!) but that would probably be a totally different way of using such tools.