GitHub user Alanxtl added a comment to the discussion: [OSPP 2026] Triple 协议性能分析与优化
**1. 使用生成的专用编码器，降低编码 CPU** 分配消掉之后，复杂消息的字段遍历、长度计算和编码本身可能成为主要开销。可以通过可选能力探测接入 `SizeVT`／`MarshalToSizedBufferVT`，继续使用池化目标缓冲区，普通消息保留现有 protobuf 路径。[vtprotobuf 文档](https://github.com/planetscale/vtprotobuf#available-features) 这更适合字段多、嵌套深的消息。PR 基准中的单个大字符串主要体现内存分配和复制，不能代表复杂业务对象的编码成本。也不能直接假设更换编码器后逐字节输出完全一致。 **2. 更大的架构方向：带生命周期管理的分段缓冲区** 让 codec 返回类似： ```text [协议头] [wrapper 元数据] [payload] ``` 各层传递缓冲区引用，消费完成后统一释放，避免为了满足连续 `[]byte` 接口而反复拼接。gRPC-Go 的 `CodecV2` 已采用 `mem.BufferSlice`，明确由框架释放编码结果，可借鉴其所有权设计。[[CodecV2 源码](https://github.com/grpc/grpc-go/blob/master/encoding/encoding_v2.go)](https://github.com/grpc/grpc-go/blob/master/encoding/encoding_v2.go) 但要获得收益，后续请求体、压缩和传输接口都得支持分段消费；中间一旦重新合并成连续内存，复制又回来了。这适合独立的架构改造。 我的实施顺序会是：**先做请求体所有权移交，再做 envelope 头部预留；随后根据真实流量选择非 IDL 融合或专用编码器。** 前两项不需要改变 wire format，收益来源也最明确。 验证时应使用真实 HTTP/2 请求，比较吞吐、P99、CPU 和峰值内存，并加入混合消息大小及不同可压缩性。当前 `io.Discard` 微基准看不到请求体复制，也看不到缓冲区移交后持有时间变长的影响。 GitHub link: https://github.com/apache/dubbo-go/discussions/3673#discussioncomment-18299674 ---- 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]
