Define a custom Scope Key for reducing memory allocations

[sairamch04]

Why ?

The current Scope Key is defined by creating a new string based on the metric tags and prefixes. This is inefficient as it ends up creating temporary strings for each metric emission. In our production service, the memory allocations due to scope key construction contribute to ~10% of the entire service allocations. This puts pressure on GC cycles, impacting the latencies of our service.

What ?

Instead of defining the key based on a temporary string(StringBuilder inside ScopeImpl.keyForPrefixedStringMap), we define it on already present objects. This will reduce unnecessary string allocations.

We create a new POJO called ScopeKey which wraps the existing tags and prefix objects, which will be the key for HashMap. HashMap internally uses hashcode() and equal() methods to determine the key. The memory of temporary string outweighs the memory of ScopeKey object as the latter has just the references to existing objects.

In short, We're changing the implementation of ScopeImpl.keyForPrefixedStringMap as part of this diff.

Benchmark results

Summary

• Throughput increased from 1099 to 2306 Ops/Sec (~109% improvement)
• Overall Memory allocation decreased from 1780 to 880 B/op (~50% improvement)
• Old Gen churn decreased from 0.24 to 0.115 B/op (~50% improvement)

Before

After

[CLAassistant]

All committers have signed the CLA.

[cdvr1993]

LGTM

[SokolAndrey]

we also keep the file with other benchmarks here, since you're changing the core part of the library could you please re-run those benchmarks and see if you change affects those

./gradlew runJmhTests

[sairamch04]

@SokolAndrey : Thanks for the review. Ran all the benchmarks in tally-core and committed it. Please take a look again.

[SokolAndrey]

lgtm! looking forward to see it in production!