You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Improve OpenDAL's latency, CPU usage, and memory footprint for idiomatic file and stream transfers across language bindings. Evaluate the same externally observable user task against the best applicable SDK API, preserving integrity, cancellation, errors, and memory limits.
Related existing work: #8159 tracks Python I/O improvements; #6226 tracks Java options coverage; #7909 tracks caller-owned backend read buffers. Reuse those efforts where applicable rather than duplicating them.
Follow-up investigations
These are investigation items, not established service defects or promised speedups. Split out implementation issues once a profile or concrete caller requirement identifies the responsible component.
C1 production/transfer overlap. The non-concurrent task path awaits work inline. For a serial producer, preparing the next input can wait for the current part to complete. Measure source-read time, request intervals, and consumer work before prototyping bounded overlap. Preserve a one-request-in-flight contract when that is the scenario; distinguish it from one application transfer. Prefer the existing unchunked reader for natural sequential consumption before optimizing a forced range workflow.
Transfer-phase memory attribution. Record live payload owners, allocator active/resident memory, HTTP/TLS buffers, and stage-specific RSS during concurrent transfers. Separate client initialization and benchmark-only verification. Successful task inputs are already released; do not diagnose retained successful parts from process-lifetime RSS alone. Evaluate bounded buffer reuse only if allocation churn is material. Exact writer staging is a possible extra chunk, not evidence of an arbitrarily large memory saving; changes must preserve small-object PUT selection, retry ownership, and error timing.
Idiomatic local-file integration. Start from concrete call sites needing file upload or download. Evaluate bounded native file input, Java read-option parity under Tracking issues for migrating Java bindings to RFC-6213 Options API #6226, and a file destination that can accept positioned writes where appropriate. Compare the SDK's native filename/WriterAt workflow, not a custom ordered Range adapter. Reuse core Reader/Writer capabilities; define source mutation, overwrite, durability, cancellation, and memory contracts before adding APIs. Keep application stream transformations supported.
Benchmark acceptance criteria
Identify a representative caller workflow and its source/sink before choosing a benchmark matrix. Ordered checksum consumption and download-to-file are separate scenarios.
Include existing natural streaming APIs. An application read size is not a transport range size, and one application transfer is not the same as internal concurrency one.
Use the actual recommended public SDK paths and resolved configuration, including integrity settings. Preserve required checksums on both sides and explicitly report capability differences.
Separate symmetric cold startup from reused-client transfer measurements. Warm the actual measured client/transport.
Use minimal implementation-specific workers and isolate benchmark-only readback verification, while completing that verification before accepting a result.
Alternate paired runs without competing load; retain exact revisions, commands, bytes/digests, resource limits, and measurement boundaries.
Validate narrow changes on the real storage workflow before expanding the matrix. Report end-to-end time, first-byte latency, CPU, and memory independently. Fewer copies or calls alone are not a throughput claim; shared network/disk/consumer limits may leave wall time unchanged.
The first implementation tranche is Java stream behavior, Python async writer ownership, and Go copy integration. Native read-boundary work follows with explicit latency and ownership contracts. Core scheduling and memory changes require attribution before implementation.
Goal
Improve OpenDAL's latency, CPU usage, and memory footprint for idiomatic file and stream transfers across language bindings. Evaluate the same externally observable user task against the best applicable SDK API, preserving integrity, cancellation, errors, and memory limits.
Scoped implementation work
Related existing work: #8159 tracks Python I/O improvements; #6226 tracks Java options coverage; #7909 tracks caller-owned backend read buffers. Reuse those efforts where applicable rather than duplicating them.
Follow-up investigations
These are investigation items, not established service defects or promised speedups. Split out implementation issues once a profile or concrete caller requirement identifies the responsible component.
Benchmark acceptance criteria
The first implementation tranche is Java stream behavior, Python async writer ownership, and Go copy integration. Native read-boundary work follows with explicit latency and ownership contracts. Core scheduling and memory changes require attribution before implementation.