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?

[AntoinePrv]

This seems to only add a new method so I think it is going to be easier for me to rebase on this in GH-50629 than the other way around.

It seems to me that the new method is not used anywhere here, so I am curious on the use case.

[Shockp]

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

Yes, that matches my understanding. This PR currently optimizes the TypedColumnReader::ReadBatch path. The Arrow-array / RecordReader path is not the main target of this change, and #50629 appears to be addressing that path more directly.

[Shockp]

This seems to only add a new method so I think it is going to be easier for me to rebase on this in GH-50629 than the other way around.

It seems to me that the new method is not used anywhere here, so I am curious on the use case.

I think there may be a small misunderstanding regarding the use of the new method.

DecodeAndCount() is used in this PR by the TypedColumnReader::ReadBatch path:

TypedColumnReaderImpl::ReadLevels()
→ ReadDefinitionLevelsAndCount()
→ LevelDecoder::DecodeAndCount()

It replaces the previous definition-level decode followed by a separate std::count() pass.

From what I understand, #50629 mainly reworks the RecordReader / Arrow-array path and introduces the bitmap-based optional-field optimization, so the two PRs seem complementary even though they touch some of the same decoder code.

I agree that rebasing #50629 on top of this PR sounds easier than the other way around. If there is anything in this API that would make that rebase harder, I'm happy to adjust it.

[AntoinePrv]

DecodeAndCount() is used in this PR by the TypedColumnReader::ReadBatch path:

Ha yes sorry, I missed that part. I was focused on the validation check.

[Shockp]

@pitrou The other developer will rebase his work on top of this. Is this PR ready to be merged, or do we need to wait?