Uh oh!
There was an error while loading. Please reload this page.
GH-3464: Improve DeltaByteArrayWriter.writeBytes to avoid unnecessary allocation and scalar prefix comparison - #3465
Merged
Merged
Conversation
…cessary allocation and scalar prefix comparison
DeltaByteArrayWriter.writeBytes to avoid unnecessary allocation and scalar prefix comparisonDeltaByteArrayWriter.writeBytes to avoid unnecessary allocation and scalar prefix comparisonFokko
approved these changes
Apr 28, 2026
Fokko
left a comment
Contributor
There was a problem hiding this comment.
Left a minor optimization, but apart from that, this looks great to me 👍
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
arouel
commented
May 4, 2026
ContributorAuthor
@Fokko thank you for the feedback. I applied your suggestions. |
Fokko
commented
May 6, 2026
Contributor
Thanks for the follow up @arouel Let's get this in, this looks great! 🙌 Thanks for introducing |
Uh oh!
There was an error while loading. Please reload this page.
abstractdog added a commit
to abstractdog/parquet-java
that referenced
this pull request
Sep 7, 2026
Replace the hand-rolled scalar byte loops in Binary#equals, Binary#lexicographicCompare, and Binary#hashCode with the JDK 9+ Arrays.equals(byte[],int,int,byte[],int,int), Arrays.compareUnsigned(byte[],int,int,byte[],int,int), Arrays.hashCode, and ByteBuffer.mismatch APIs. These range overloads route through ArraysSupport.vectorizedMismatch, an @IntrinsicCandidate helper HotSpot substitutes with a SIMD byte-scan (SSE / AVX2 / NEON on modern hardware). Measured on this project's BinaryComparisonBenchmark (JDK 17, 1 fork, 3x1s warmup, 5x1s measurement, throughput): equalsMatch_bytesBytes len=512 9.1M -> 39.1M ops/s (4.30x) equalsMatch_bytesBytes len= 64 41.4M -> 160.9M ops/s (3.89x) equalsMismatch_bytesBytes len=512 14.6M -> 55.5M ops/s (3.79x) compareTo_bytesBytes len=512 15.1M -> 58.8M ops/s (3.91x) compareTo_bytesBytes len= 64 59.0M -> 199.4M ops/s (3.38x) equalsMismatch_bytesBuf len= 64 63.8M -> 190.2M ops/s (2.98x) Short values (len=8) see only 1.1-1.7x because there's barely enough work for one SIMD lane. hashCode is separate. The 31*h+b polynomial has a serial dependency across iterations, so SIMD needs a lane-split algebraic trick that HotSpot only gained in JDK 21 (via ArraysSupport.vectorizedHashCode, which is @IntrinsicCandidate). On JDK 17 -- this project's target -- Arrays.hashCode is a plain scalar loop and shows no measured speedup here. The call is kept for forward compatibility: JDK 21+ runtimes pick up the vectorized intrinsic silently; a bespoke loop would stay stuck at scalar. These primitives sit on Binary equality, comparison and hash-map probing, which is the hot code path for statistics min/max maintenance, dictionary probing, predicate evaluation, and bloom-filter build -- i.e. broadly amortized across reader and writer. Semantics are preserved bit-for-bit: - hashCode(byte[]) uses the same 31*h + b polynomial (Arrays.hashCode on full arrays; the polynomial expanded for slices). - equals is bytewise identity. - lexicographicCompare is unsigned bytewise with shorter-first tie-break on prefix match, matching Arrays.compareUnsigned's contract. The change is JIT-friendly across the four Binary/Binary shape pairs (byte[]/byte[], byte[]/ByteBuffer, ByteBuffer/ByteBuffer) and for heap-backed ByteBuffers unwraps to the intrinsic byte[] path via buffer.array(). Follows the same technique already accepted for DeltaByteArrayWriter in PR apache#3465. Complementary to the Binary hashCode caching in the open dictionary-optimization PR apache#3566: caching reduces call frequency; intrinsics speed up the calls that remain plus equals/compareTo which caching does not address. Includes a JMH micro-benchmark (parquet-benchmarks/BinaryComparisonBenchmark) covering equals / compareTo / hashCode across length regimes 8, 64 and 512 for the three Binary shape combinations, with both worst-case (full match) and average-case (mid-length mismatch) inputs.
abstractdog added a commit
to abstractdog/parquet-java
that referenced
this pull request
Sep 7, 2026
Replace the hand-rolled scalar byte loops in Binary#equals, Binary#lexicographicCompare, and Binary#hashCode with the JDK 9+ Arrays.equals(byte[],int,int,byte[],int,int), Arrays.compareUnsigned(byte[],int,int,byte[],int,int), Arrays.hashCode, and ByteBuffer.mismatch APIs. These range overloads route through ArraysSupport.vectorizedMismatch, an @IntrinsicCandidate helper HotSpot substitutes with a SIMD byte-scan (SSE / AVX2 / NEON on modern hardware). Measured on this project's BinaryComparisonBenchmark (JDK 17, 1 fork, 3x1s warmup, 5x1s measurement, throughput): equalsMatch_bytesBytes len=512 9.1M -> 39.1M ops/s (4.30x) equalsMatch_bytesBytes len= 64 41.4M -> 160.9M ops/s (3.89x) equalsMismatch_bytesBytes len=512 14.6M -> 55.5M ops/s (3.79x) compareTo_bytesBytes len=512 15.1M -> 58.8M ops/s (3.91x) compareTo_bytesBytes len= 64 59.0M -> 199.4M ops/s (3.38x) equalsMismatch_bytesBuf len= 64 63.8M -> 190.2M ops/s (2.98x) Short values (len=8) see only 1.1-1.7x because there's barely enough work for one SIMD lane. hashCode is separate. The 31*h+b polynomial has a serial dependency across iterations, so SIMD needs a lane-split algebraic trick that HotSpot only gained in JDK 21 (via ArraysSupport.vectorizedHashCode, which is @IntrinsicCandidate). On JDK 17 -- this project's target -- Arrays.hashCode is a plain scalar loop and shows no measured speedup here. The call is kept for forward compatibility: JDK 21+ runtimes pick up the vectorized intrinsic silently; a bespoke loop would stay stuck at scalar. These primitives sit on Binary equality, comparison and hash-map probing, which is the hot code path for statistics min/max maintenance, dictionary probing, predicate evaluation, and bloom-filter build -- i.e. broadly amortized across reader and writer. Semantics are preserved bit-for-bit: - hashCode(byte[]) uses the same 31*h + b polynomial (Arrays.hashCode on full arrays; the polynomial expanded for slices). - equals is bytewise identity. - lexicographicCompare is unsigned bytewise with shorter-first tie-break on prefix match, matching Arrays.compareUnsigned's contract. The change is JIT-friendly across the four Binary/Binary shape pairs (byte[]/byte[], byte[]/ByteBuffer, ByteBuffer/ByteBuffer) and for heap-backed ByteBuffers unwraps to the intrinsic byte[] path via buffer.array(). Follows the same technique already accepted for DeltaByteArrayWriter in PR apache#3465. Complementary to the Binary hashCode caching in the open dictionary-optimization PR apache#3566: caching reduces call frequency; intrinsics speed up the calls that remain plus equals/compareTo which caching does not address. Includes a JMH micro-benchmark (parquet-benchmarks/BinaryComparisonBenchmark) covering equals / compareTo / hashCode across length regimes 8, 64 and 512 for the three Binary shape combinations, with both worst-case (full match) and average-case (mid-length mismatch) inputs.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for freeto join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Rationale for this change
DeltaByteArrayWriter.writeBytes()is on the hot path forDELTA_BYTE_ARRAYencoding and had avoidable overhead:Per-value allocation from
getBytes().getBytes()always creates a new array. For prefix comparison this copy is unnecessary.Scalar prefix scan.
The byte-by-byte loop is replaced with
Arrays.mismatch(...), which maps to optimized JVM intrinsics.In profiling (custom JFR benchmark on a large merge workload), this method was a top allocation hotspot before the change.
What changes are included in this PR?
In
DeltaByteArrayWriter.writeBytes():v.getBytes()->v.getBytesUnsafe()for read-only prefix comparison.Arrays.mismatch(previous, 0, length, vb, 0, length).previous = vb->previous = v.isBackingBytesReused() ? v.getBytes() : vb(defensive copy only when the backing bytes may be reused by the caller).
This preserves semantics while removing unnecessary allocations in the common case.
Benchmark signal (custom, directional)
On a custom JFR-profiled merge workload (180M rows, 4 binary columns), this change significantly reduced allocations and lowered CPU attributed to this path.
(Results are workload/JDK dependent and provided as directional evidence.)
Are these changes tested?
Yes.
TestDeltaByteArrayround-trip tests (including skip/skipN/reset paths).testReusedBackingArrayRegressioninTestDeltaByteArrayto verify correctness when the same mutable backing array is reused across writes.Are there any user-facing changes?
No API or format changes. This is a transparent performance optimization; encoded data remains compatible/interchangeable.
Closes#3464