GH-45594: [C++][Parquet] POC: Optimize Parquet DecodeArrow in DeltaLengthByteArray

[mapleFU]

Rationale for this change

See #45594

What changes are included in this PR?

1. Add a hack interface for binary builder
2. Optimize decoding in DeltaLengthByteArray

Are these changes tested?

Covered by existing

Are there any user-facing changes?

no

• GitHub Issue: [C++][Parquet] Optimize Parquet DecodeArrow in DeltaLengthByteArray #45594

[github-actions]

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

[mapleFU]

On my MacOS:

After:

BM_ArrowBinaryDeltaLength/DL_DecodeArrow_Dense/1024        1803 ns         1794 ns       366634 bytes_per_second=3.27674G/s items_per_second=570.698M/s
BM_ArrowBinaryDeltaLength/DL_DecodeArrow_Dense/4096        5502 ns         5453 ns       129056 bytes_per_second=4.21124G/s items_per_second=751.186M/s
BM_ArrowBinaryDeltaLength/DL_DecodeArrow_Dense/32768      39024 ns        38960 ns        17944 bytes_per_second=4.68932G/s items_per_second=841.076M/s
BM_ArrowBinaryDeltaLength/DL_DecodeArrow_Dense/65536      76109 ns        76037 ns         9217 bytes_per_second=4.79637G/s items_per_second=861.897M/s

Before:

BM_ArrowBinaryDeltaLength/DL_DecodeArrow_Dense/1024       11620 ns        10801 ns        55154 bytes_per_second=557.395M/s items_per_second=94.8042M/s
BM_ArrowBinaryDeltaLength/DL_DecodeArrow_Dense/4096       51641 ns        51339 ns        13196 bytes_per_second=458.007M/s items_per_second=79.7829M/s
BM_ArrowBinaryDeltaLength/DL_DecodeArrow_Dense/32768     479142 ns       459910 ns         1550 bytes_per_second=406.772M/s items_per_second=71.2488M/s
BM_ArrowBinaryDeltaLength/DL_DecodeArrow_Dense/65536     963371 ns       929585 ns          759 bytes_per_second=401.743M/s items_per_second=70.5003M/s

[mapleFU]

cc @pitrou this interface is a bit ugly but I don't know whether we have better way for this. Would you mind take a look?

[pitrou]

Why not call this AppendValuesWithLengths?
Also, it should probably take the right offset type?
And you need to add a docstring...

Suggested change

	Status AppendBinaryWithLengths(std::string_view binary, const int32_t* value_lengths,
	int64_t length) {
	/// XXX docstring
	Status AppendValuesWithLengths(std::string_view binary, util::span<const offset_type> lengths) {

[pitrou]

Why not check equality? It's trivial to call substr on a std::string_view.

Suggested change

	if (ARROW_PREDICT_FALSE(binary.size() < static_cast<size_t>(accum_length))) {
	return Status::Invalid("Binary data is too short");
	}
	if (ARROW_PREDICT_FALSE(binary.size() != static_cast<size_t>(accum_length))) {
	return Status::Invalid("Binary size does not match lengths array");
	}

[pitrou]

Let's call ValidateOverflow instead?

[pitrou]

Suggested change

	const int64_t initialize_offset = value_data_builder_.length();
	const int64_t initial_offset = value_data_builder_.length();

[pitrou]

Same comments below...

[pitrou]

Can you call these after the error checks below?

[pitrou]

Can you use the same naming as above? e.g. initial_offset

[pitrou]

Hmm, we're not incrementing length_idx here? This is not usual in Builder APIs, I don't think this is a good idea.

[pitrou]

Hmm, I really don't like the new BinaryBuilder API that this is adding.

Perhaps we should instead add these APIs and let Parquet use those builders?

diff --git a/cpp/src/arrow/array/builder_binary.h b/cpp/src/arrow/array/builder_binary.h
index 442e4a2632..e568279508 100644
--- a/cpp/src/arrow/array/builder_binary.h
+++ b/cpp/src/arrow/array/builder_binary.h
@@ -359,6 +359,9 @@ class BaseBinaryBuilder
   /// \return data pointer of the value date builder
   const offset_type* offsets_data() const { return offsets_builder_.data(); }
 
+  TypedBufferBuilder<offset_type>* offsets_builder() { return &offsets_builder_; }
+  TypedBufferBuilder<uint8_t>* value_data_builder() { return &value_data_builder_; }
+
   /// Temporary access to a value.
   ///
   /// This pointer becomes invalid on the next modifying operation.

[mapleFU]

Perhaps we should instead add these APIs and let Parquet use those builders?

Previously I've using a poc like this, maybe unsafe or other prefix can make this better?

diff --git a/cpp/src/arrow/array/builder_binary.h b/cpp/src/arrow/array/builder_binary.h
index 442e4a2632..e568279508 100644
--- a/cpp/src/arrow/array/builder_binary.h
+++ b/cpp/src/arrow/array/builder_binary.h
@@ -359,6 +359,9 @@ class BaseBinaryBuilder
   /// \return data pointer of the value date builder
   const offset_type* offsets_data() const { return offsets_builder_.data(); }
 
+  TypedBufferBuilder<offset_type>* unsafe_offsets_builder() { return &offsets_builder_; }
+  TypedBufferBuilder<uint8_t>* unsafe_value_data_builder() { return &value_data_builder_; }
+
   /// Temporary access to a value.
   ///
   /// This pointer becomes invalid on the next modifying operation.

[pitrou]

I don't think adding "unsafe" would really bring anything (there is no risk of crashing, for instance). However, we should add a docstring explaining the caveats when using these methods.