The Blob.Data property is currently typed as byte[]. When callers already hold image or file bytes in a zero-copy buffer — for example, as a ReadOnlyMemory segment, a pooled ArraySegment, or a Protobuf ByteString — they are forced to call .ToArray() before assigning to Blob.Data. This produces a full copy of the underlying bytes on the managed heap (potentially several megabytes per request) whose sole purpose is to satisfy the byte[] type requirement; the data itself is otherwise identical.
Impact
Increased GC pressure, particularly in high-throughput scenarios where GenerateContentAsync is called frequently (e.g. per-frame or per-session image analysis loops).
Higher peak memory usage, since the copy lives alongside the original buffer until the GC collects it.
Missed zero-copy opportunity: modern .NET APIs (System.IO.Pipelines, System.Memory, IMemoryOwner) are designed around ReadOnlyMemory / ReadOnlySpan precisely to avoid this pattern.
Proposed change
Add an overload or change the storage type of Blob.Data to accept ReadOnlyMemory. Concretely, one or a combination of:
Constructor overload — add Blob(ReadOnlyMemory data, string mimeType) that stores data without copying.
Factory method — Blob.FromMemory(ReadOnlyMemory data, string mimeType).
Property type change — change Data from byte[] to ReadOnlyMemory (binary-breaking, but aligns with modern .NET best practices).
Option 1 or 2 is the least disruptive because the existing byte[] property stays as-is for backward compatibility, and only the internal storage path changes.
The Blob.Data property is currently typed as byte[]. When callers already hold image or file bytes in a zero-copy buffer — for example, as a ReadOnlyMemory segment, a pooled ArraySegment, or a Protobuf ByteString — they are forced to call .ToArray() before assigning to Blob.Data. This produces a full copy of the underlying bytes on the managed heap (potentially several megabytes per request) whose sole purpose is to satisfy the byte[] type requirement; the data itself is otherwise identical.
Impact
Increased GC pressure, particularly in high-throughput scenarios where GenerateContentAsync is called frequently (e.g. per-frame or per-session image analysis loops).
Higher peak memory usage, since the copy lives alongside the original buffer until the GC collects it.
Missed zero-copy opportunity: modern .NET APIs (System.IO.Pipelines, System.Memory, IMemoryOwner) are designed around ReadOnlyMemory / ReadOnlySpan precisely to avoid this pattern.
Proposed change
Add an overload or change the storage type of Blob.Data to accept ReadOnlyMemory. Concretely, one or a combination of:
Constructor overload — add Blob(ReadOnlyMemory data, string mimeType) that stores data without copying.
Factory method — Blob.FromMemory(ReadOnlyMemory data, string mimeType).
Property type change — change Data from byte[] to ReadOnlyMemory (binary-breaking, but aligns with modern .NET best practices).
Option 1 or 2 is the least disruptive because the existing byte[] property stays as-is for backward compatibility, and only the internal storage path changes.