GitHub user Alanxtl added a comment to the discussion: [OSPP 2026] Triple
协议性能分析与优化
目前 Unary 快速通道的链路是：
```text
消息 → MarshalAppend 写入池化缓冲区 A
→ unaryFastPathCall.Write
→ 复制到池化请求体 B
→ HTTP transport
```
复制明确发生在 unary_fastpath.go:148
可以增加内部的“接收完整请求体”接口，让发送端直接接管 A：
```text
消息 → 池化缓冲区 A → 移交给 Request.Body → Body.Close 时归还
```
这样能够：
- 消除一次 O(L) 的完整 payload 复制。
- 减少发送准备阶段同时持有的缓冲区。
- 压缩场景直接移交压缩结果，省掉压缩数据到请求体的复制。
关键是明确“成功接管后谁负责释放”，覆盖取消、发送失败、尚未提交请求等路径。**不能在 `http.Client.Do` 返回时直接归还**，因为
transport 可能仍在异步读取请求体；应沿用现有 `unaryRequestBody.Close` 的释放机制。[Go HTTP
契约](https://pkg.go.dev/net/http#RoundTripper)
这里消除的是应用层的一次复制，HTTP/2、TLS 内部仍可能复制。
以及把 gRPC 的 5 字节头与 payload 一起构造
当前 envelope.go:147 分别写入 prefix 和 payload。
可以在池化缓冲区前预留 5 字节：
```text
[ flags | payload length | MarshalAppend 的结果 ]
编码完成后回填
```
再整体移交给 Unary 请求体。压缩时，在压缩输出缓冲区预留头，填入实际压缩长度。
这有机会同时消除独立 prefix 的逃逸分配，并减少 `Write` 调用和请求体锁操作。**应在编码前预留空间**，否则事后移动整份 payload
会抵消收益。两次 `Write` 也不等于两次系统调用，收益需要实测。
GitHub link:
https://github.com/apache/dubbo-go/discussions/3673#discussioncomment-18299667
----
This is an automatically sent email for [email protected].
To unsubscribe, please send an email to:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
