Files
HomeAgent/internal/plugin/proc
JianFeeeee a006237105 test(proc): 建立进程间通信的成本地板(判定「优化 IPC」的空间)
目标:回答「工具调用往返 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 全量测试绿。
2026-09-26 13:06:10 +08:00
..