mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-09-26 12:23:23 +00:00
a006237105
目标：回答「工具调用往返 30µs 里，非编解码的 ~20µs 花在哪、能否优化」。 方法：先立地板 —— 任何跨进程方案都有 OS 调度决定的下界。 三层对照（同机同会话，3000 次迭代）： | 层 | ns/op | allocs | |---|---:|---:| | ① OS 调度地板（cat 子进程管道 echo，无协议无 JSON） | **16071** | 0 | | ② 最简 RPC（无载荷、不经共享帧） | **25840** | 20 | | ③ 纯编解码（共享段 write+read+compact，纯内存） | 10200 | 84 | ## 两条判据 1. **① 已占 ② 的 62%**：一个什么都不做的 echo（两次进程唤醒 + 两次管道读写）就要 16µs。⇒ RPC 层的成本主要是 **OS 调度**， 不是协议解析或 JSON 序列化。 2. **②−① 只剩约 10µs**：这才是协议层（JSON 帧 + pending map + channel 握手）可优化的全部空间，且其中还包含一次真实的 JSON 编解码往返。⇒ 「优化 IPC」的理论上限约为端到端 30µs 的三分之一。 ## 结论 跨进程数据面的**协议侧已接近其地板**。若要把端到端再压下去， 方向不是「优化协议」，而是**改变通信形态本身**： · 批量调用（一次往返做多件事，摊薄固定调度成本） · 或对高频小调用改走共享内存 + 自旋/事件通知（绕过两次进程唤醒） 两者都是架构级改动，不是参数调优。 ★ 这也解释了此前几轮的困惑：为什么 C 化数据面收益总是很小 —— 因为真正的大头（OS 调度 16µs）与语言无关。 验证：基准可复现；internal/plugin/proc 全量测试绿。