Improve TSDB codec benchmarks with full encoder and compression metrics

[salvatore-campagna]

The existing TSDB codec benchmarks only measure the bit-packing step (DocValuesForUtil), which doesn't reflect actual codec performance. The real encoder applies multiple compression stages before bit-packing: delta encoding to reduce value magnitudes, minimum offset removal, and GCD computation to find common divisors. This PR updates the benchmarks to use TSDBDocValuesEncoder, which runs the full encoding pipeline and gives us realistic performance numbers.

These benchmarks are designed to capture compression/throughput tradeoffs when evaluating new encoding techniques. By measuring both compression efficiency and encoding speed, we can make informed decisions about whether a new compression algorithm is worth the performance cost. A technique that achieves 20% better compression but runs 50% slower may not be worthwhile for high-throughput indexing workloads. Moreover, measuring throughput at both encode and decode time is important because encoding throughput directly impacts indexing performance, while decoding throughput affects query latency.

With these improvements, we can run the benchmarks against the current encoder implementation to establish baseline results. Future encoder changes can then use these baselines as a reference point for comparison.

This PR introduces two auxiliary counter classes and refactors the benchmark base class:

• CompressionMetrics: uses @AuxCounters(Type.EVENTS) to report compression statistics including encodedBytesPerValue, compressionRatio (raw size divided by encoded size), encodedBitsPerValue, and overheadRatio (ratio of actual encoded size to theoretical minimum where 1.0 means optimal encoding)
• ThroughputMetrics: uses @AuxCounters(Type.OPERATIONS) to report encodedBytes and valuesProcessed which JMH normalizes by time to produce bytes/s and values/s rates, enabling fair comparison across different block sizes
• AbstractTSDBCodecBenchmark: renamed from AbstractDocValuesForUtilBenchmark and refactored using Template Method pattern where subclasses implement run() for the core operation (encode or decode) and getOutput() for blackhole consumption, while benchmark(Blackhole) combines both

Encode benchmarks provide two methods: throughput() for measuring encoding speed with ThroughputMetrics, and compression() for measuring compression efficiency with CompressionMetrics. Decode benchmarks provide only throughput() since compression metrics are a property of the encoded data, not the decoding process.

Benchmarks are parameterized by bitsPerValue at encoding boundaries where ForUtil and DocValuesForUtil switch between different code paths. Testing at these boundaries ensures we catch performance regressions at all the important transitions where the encoder selects different strategies.

Running the benchmarks

# Encode throughput
./gradlew :benchmarks:run --args='.*Encode.*IntegerBenchmark.throughput'

# Encode compression
./gradlew :benchmarks:run --args='.*Encode.*IntegerBenchmark.compression'

# Decode throughput
./gradlew :benchmarks:run --args='.*Decode.*IntegerBenchmark.throughput'

[salvatore-campagna]

I don't like having this here...I will see if I can move it outside or pass values to the benchmark directly.

[elasticsearchmachine]

Pinging @elastic/es-storage-engine (Team:StorageEngine)

[martijnvg]

Thanks Salvatore 👍

I do wonder whether we should also benchmark encodeOrdinals and decodeOrdinals? Maybe in a follow up?

[salvatore-campagna]

Thanks Salvatore 👍

I do wonder whether we should also benchmark encodeOrdinals and decodeOrdinals? Maybe in a follow up?

Thanks @martijnvg . Yes I am planning to benchmark those too. I am just splitting all PRs to make reviewing easier and reduce scope.