Method dispatch: hotspot metric
At each callsite (source code point, where method dispatch happens) we can count
1) number of calls to a method
2) time spent inside the method
3) time spent in callsite (total time across all methods called at the point).
Time can be measured either in byte code instructions, machine instructions or in microseconds.
Lets look at possible situations:
| Callsite time | Number of calls | Description |
|---|---|---|
| Small | Low | Rarely called unimportant method |
| Big | Low | “main”-like method: entry point to a fat logic |
| Small | High | Efficiently implemented frequently called method |
| Big | High | Frequently called and slow method: subject for optimization |
In real code, we don’t meet frequently called very slow methods: it is often done by bad design and could not be efficiently optimized in runtime. But this chart helps us to define a metric for “hot spot” identification: the place in the code, where we start runtime optimization.
Such “hotspot” metric would be callsite time * number of calls. The higher this number, the higher priority should be given to such callsite at optimization phase.
Why don’t we just start with a top-level method? If we start from the very top, we would spend enormous amount of time optimizing the whole program instead of really interesting parts.