[jira] [Updated] (OAK-12446) Reduce temporary buffer allocations in segment string decoding and blob reads

["Nuno Santos (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OAK-12446?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nuno Santos updated OAK-12446:
------------------------------
    Description: 
h2. Motivation

Segment reads create intermediate Buffer/ByteBuffer views when copying a range into a byte array. These views are unnecessary for callers that already have a destination array, including string decoding and some blob-read paths.

Introduce an absolute bulk-read path that copies directly into the destination array without changing the source buffer position or limit. This should reduce temporary allocations and decoding overhead in hot segment-read paths.
h2. Proposed changes
 * Add Buffer.get(int index, byte[] destination, int offset, int length), delegating to the corresponding ByteBuffer operation.
 * Add a destination-array bulk-read overload to SegmentData and implement it for the supported segment-data formats.
 * Route Segment.readBytes(...) through that overload instead of obtaining an intermediate sliced buffer.
 * Use the direct-copy path in SegmentData.decodeString(...) and short blob-ID decoding, constructing the resulting String from the byte array with UTF-8.
 * Update exported package versions as required by the baseline checks, and consider compatibility for existing SegmentData implementations when choosing the interface contract.

h2. Compatibility

The optimized segment readers require the new oak-commons API at runtime. Consumers embedding the segment libraries while importing oak-commons must upgrade that runtime dependency before adopting the optimized readers. The new absolute read must preserve source buffer state so concurrent readers do not interfere.

  was:
h2. Motivation

Segment reads create intermediate Buffer/ByteBuffer views when copying a range into a byte array. These views are unnecessary for callers that already have a destination array, including string decoding and some blob-read paths.

Introduce an absolute bulk-read path that copies directly into the destination array without changing the source buffer position or limit. This should reduce temporary allocations and decoding overhead in hot segment-read paths.

h2. Proposed changes
* Add Buffer.get(int index, byte[] destination, int offset, int length), delegating to the corresponding ByteBuffer operation.
* Add a destination-array bulk-read overload to SegmentData and implement it for the supported segment-data formats.
* Route Segment.readBytes(...) through that overload instead of obtaining an intermediate sliced buffer.
* Use the direct-copy path in SegmentData.decodeString(...) and short blob-ID decoding, constructing the resulting String from the byte array with UTF-8.
* Update exported package versions as required by the baseline checks, and consider compatibility for existing SegmentData implementations when choosing the interface contract.

h2. Validation

Add regression tests for source and destination offsets, untouched destination bytes, zero-length reads, invalid ranges, heap/direct/read-only buffers, preservation of source buffer position and limit, supported segment-data formats, multibyte UTF-8 strings, and short blob-ID decoding.

Include before/after microbenchmark results for throughput and allocation rate. End-to-end gains should be measured separately rather than inferred from a microbenchmark.

h2. Compatibility

The optimized segment readers require the new oak-commons API at runtime. Consumers embedding the segment libraries while importing oak-commons must upgrade that runtime dependency before adopting the optimized readers. The new absolute read must preserve source buffer state so concurrent readers do not interfere.


> Reduce temporary buffer allocations in segment string decoding and blob reads
> -----------------------------------------------------------------------------
>
>                 Key: OAK-12446
>                 URL: https://issues.apache.org/jira/browse/OAK-12446
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: commons, segment-tar
>            Reporter: Nuno Santos
>            Priority: Major
>
> h2. Motivation
> Segment reads create intermediate Buffer/ByteBuffer views when copying a range into a byte array. These views are unnecessary for callers that already have a destination array, including string decoding and some blob-read paths.
> Introduce an absolute bulk-read path that copies directly into the destination array without changing the source buffer position or limit. This should reduce temporary allocations and decoding overhead in hot segment-read paths.
> h2. Proposed changes
>  * Add Buffer.get(int index, byte[] destination, int offset, int length), delegating to the corresponding ByteBuffer operation.
>  * Add a destination-array bulk-read overload to SegmentData and implement it for the supported segment-data formats.
>  * Route Segment.readBytes(...) through that overload instead of obtaining an intermediate sliced buffer.
>  * Use the direct-copy path in SegmentData.decodeString(...) and short blob-ID decoding, constructing the resulting String from the byte array with UTF-8.
>  * Update exported package versions as required by the baseline checks, and consider compatibility for existing SegmentData implementations when choosing the interface contract.
> h2. Compatibility
> The optimized segment readers require the new oak-commons API at runtime. Consumers embedding the segment libraries while importing oak-commons must upgrade that runtime dependency before adopting the optimized readers. The new absolute read must preserve source buffer state so concurrent readers do not interfere.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)