Skip to content

tracking: improve cross-language file and stream transfer efficiency #8251

Description

@Xuanwo

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.

  • 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.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions