fix(storage): optimize gRPC writer with zero-copy and lazy allocation#13481
Conversation
Summary of ChangesHello @cpriti-os, I'm Gemini Code Assist1! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed! This pull request significantly optimizes the gRPC writer by eliminating unnecessary double-buffering, which can reduce memory usage by up to 50% for large file uploads and parallel composite uploads. The core improvements involve introducing a zero-copy path for efficient data transfer and implementing lazy allocation for the internal write buffer, ensuring that memory is only used when strictly necessary. Highlights
Using Gemini Code AssistThe full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips. Invoking Gemini You can request assistance from Gemini at any point by creating a comment using either
Customization To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a Limitations & Feedback Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here. You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension. Footnotes
|
There was a problem hiding this comment.
Code Review
This pull request introduces a significant optimization to the gRPC writer by implementing a zero-copy path and lazy allocation of the internal buffer. The changes are well-structured, and the logic for handling zero-copy writes, including partial sends and retries, appears robust. The addition of comprehensive tests that verify memory addresses is excellent and provides strong confidence in the correctness of the optimization. I've found one potential issue regarding integer overflow on 32-bit systems, for which I've left a specific comment. Overall, this is a great improvement for memory efficiency.
Co-authored-by: gemini-code-assist[bot] <176961590+gemini-code-assist[bot]@users.noreply.github.com>
tritone
left a comment
There was a problem hiding this comment.
Great optimization!
Looks like there are some failing emulator tests involving progress func callbacks, race detector issues, and a deadlock. LMK if you have any questions about any of these. Probably you'll need to work on thread safety between the buffer alloc and the pipelined sends.
In addition we'd probably want to think about how to message this -- does this change how the writer "should" be used for gRPC? Do we want to suggest buffer pooling in the user application?
Finally, it'd be useful to get a pprof CPU/memory profile for before/after on this.
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces a zero-copy optimization and lazy buffer allocation for the gRPC writer, which is a great improvement for memory efficiency. The implementation looks solid, especially the retry logic in the zero-copy path. I've found a couple of areas for improvement: one is a potential memory leak issue in the new zero-copy logic, and the other is an issue in the new tests that causes them to not correctly verify the new behavior. My detailed comments are below.
|
Approving based on the changes. Just check if the synchronous nature of the single shot write does not qualify for a breaking change. |
tritone
left a comment
There was a problem hiding this comment.
Generally looks good, a few questions
PR created by the Librarian CLI to initialize a release. Merging this PR will auto trigger a release. Librarian Version: v0.8.3 Language Image: us-central1-docker.pkg.dev/cloud-sdk-librarian-prod/images-prod/librarian-go@sha256:19bb93e8f1f916c61b597db2bad65dc432f79baaabb210499d7d0e4ad1dffe29 <details><summary>storage: v1.61.0</summary> ## [v1.61.0](storage/v1.60.0...storage/v1.61.0) (2026-03-10) ### Features * add bucket encryption enforcement configuration (#13874) ([245c8d7](245c8d76)) * add multistream options to MRD (#13758) ([4557675](4557675e)) * add a DeleteFolderRecursive API definition (PiperOrigin-RevId: 866471251) ([6f31019](6f310199)) * add multistream support to MRD (#13792) ([ffa7268](ffa7268c)) ### Bug Fixes * Fix TM download dir corner case (#14142) ([87cdcc9](87cdcc9f)) * Omit auto checksum in final request when MD5 is given (#14024) ([d404777](d4047774)) * optimize gRPC writer with zero-copy and lazy allocation (#13481) ([df64147](df641476)) </details>
This change eliminates unnecessary double-buffering in the gRPC writer,
reducing memory usage by up to 50% for Parallel Composite Uploads (PCU)
and large single-shot uploads.
Key changes:
gRPCWriter: if in one-shot mode, the writer nowpasses the user's memory directly to the gRPC transport layer instead
of copying it into an internal buffer.
w.buf) is nowinitialized to
niland is only allocated if the "Slow Path" (buffering)is triggered. This allows purely zero-copy workloads to run with
near-zero overhead.
chunkSizetogRPCWriterto support logic whenw.bufis nil.optimization is active and strictly correct during retries.