GH-48561: [C++][Parquet] Optimize column reader by fusing definition level decoding with counting

[Shockp]

Rationale for this change

Definition levels in the Parquet column reader are currently decoded into
a buffer and then scanned separately with std::count to determine how
many physical values need to be decoded.

This adds an extra pass over the decoded definition levels.

For RLE-encoded levels, the number of matching values can often be
determined directly from the run value and run length while the output is
being materialized.

What changes are included

• Add GetBatchAndCount support to the RLE and bit-packed decoders.
• For repeated RLE runs, compute the matching count directly from run
  metadata without scanning the decoded output.
• For bit-packed runs, count the values immediately after unpacking them.
• Add LevelDecoder::DecodeAndCount, preserving the existing level
  validation.
• Use the fused decode-and-count operation when reading Parquet definition
  levels.
• Remove the separate std::count pass from the column reader.
• Add targeted benchmarks comparing the separate and fused approaches.

Benchmarks

parquet-column-reader-benchmark, pinned to one CPU, 20 repetitions.

Encoding	Max level	Batch	Repeat	Separate	Fused	Change
RLE	1	1024	1	5555.5 ns	5383.5 ns	3.10% faster
RLE	1	1024	7	13464.7 ns	10972.1 ns	18.51% faster
RLE	1	1024	1024	4111.3 ns	971.7 ns	76.36% faster
RLE	3	1024	1	5500.5 ns	5003.0 ns	9.04% faster
RLE	3	2048	1	5384.0 ns	4778.2 ns	11.25% faster
RLE	3	1024	7	14184.0 ns	11833.4 ns	16.57% faster
BitPack	1	1024	1	4001.3 ns	3953.2 ns	1.20% faster
BitPack	1	1024	7	3996.6 ns	3949.6 ns	1.18% faster
BitPack	1	1024	1024	3974.4 ns	3988.0 ns	0.34% slower
BitPack	3	1024	1	3940.1 ns	3974.0 ns	0.86% slower
BitPack	3	2048	1	3895.6 ns	3881.6 ns	0.36% faster
BitPack	3	1024	7	3956.2 ns	3919.4 ns	0.93% faster

The improvement increases with RLE run length because matching values can
be counted from run metadata instead of rescanning the materialized output.
The bit-packed path remains approximately neutral.

Closes #48561.

• GitHub Issue: [C++][Parquet] Optimize column reader by fusing definition level decoding with counting #48561

[github-actions]

⚠️ GitHub issue #48561 has been automatically assigned in GitHub to PR creator.

[wgtmac]

@AntoinePrv Could you help review this please?

[pitrou]

Something like this was already attempted in #50682, how is this one different?

[pitrou]

@ursabot please benchmark lang=C++

[rok]

Benchmark runs are scheduled for commit 9e4a871. Watch https://buildkite.com/apache-arrow and https://conbench.arrow-dev.org for updates. A comment will be posted here when the runs are complete.

[Shockp]

Something like this was already attempted in #50682, how is this one different?

I am on holidays till Sunday. I will read that PR deeper. But it seems he tried a different approach. I will wait for the benchmark results as well.

[Shockp]

@wgtmac is it bugged the benchmark? It was started 4 days ago.

[pitrou]

@Shockp The results weren't posted here apparently but you can find them there:

• https://conbench.arrow-dev.org/compare/runs/db22f133547c41009024be6758996ef6...379269722a274e6fa60c91c18f78f03a/
• https://conbench.arrow-dev.org/compare/runs/0dae918efb9548e8bb8fda899e10eb40...42bc72ab52c64f63ab2414ae321b166f/

[Shockp]

@Shockp The results weren't posted here apparently but you can find them there:

• https://conbench.arrow-dev.org/compare/runs/db22f133547c41009024be6758996ef6...379269722a274e6fa60c91c18f78f03a/
• https://conbench.arrow-dev.org/compare/runs/0dae918efb9548e8bb8fda899e10eb40...42bc72ab52c64f63ab2414ae321b166f/

Which were your conclusion about the results? I think there are some good improvements and not many regressions.

[pitrou]

@Shockp Agreed. It also seems that only the ReadBatch API is improved? Reading to an Arrow array doesn't seem to have improved significantly.

[pitrou]

This may also conflict heavily with the optimizations @AntoinePrv is working on in #50629. Can both of you discuss how to reconcile these?