HomeAgent

jianf/HomeAgent

Fork 0

mirror of https://gitcode.com/JianFeeeee/HomeAgent.git synced 2026-09-21 17:38:10 +00:00

Commit Graph

Author	SHA1	Message	Date
JianFeeeee	b71a88a471	chore(shm): 补齐 §13 验证项，删除统一区域遗留死代码三件事，都是 plan.md §13 里未打勾的项： 1. §13.3「Bench: ToolInvoke 延迟对比」补测（bench_test.go）改造后原有的 BenchmarkToolInvoke 仍走 legacy 内联 Args，已不代表生产路径。拆成 inline / frame 两个子基准并各测两个尺寸（-count=3 取中位）： payload inline（RPC 报文） frame（共享内存帧）差 16 B 26.4 µs/op 48.0 µs/op +21.6 µs 32 KiB 695.6 µs/op 391.7 µs/op −303.9 µs 取舍随尺寸翻转：小 payload 多付 ~22µs 帧固定开销，大 payload 省掉整份 JSON 编解码与管道拷贝、快 44%。因为线上工具结果动辄几十 KB 且 22µs 相对 LLM 往返 2-8 秒可忽略，所以统一走帧而不按大小分叉（§13.3 第 4 条）是对的。 2. 删除 §13.1 遗留死代码（evtring.go） allocEvtRing 自统一共享区域之后从未被调用——旧版它单独建 memfd + eventfd，现在只有一个 memfd，事件环只是区内的一个 segment（NewEvtRing 操作区内切片）。留着会让人误以为事件环还有独立段。 3. 修正误导性注释（plugin.go）仍写着旧 3-fd 布局「3=StageContext, 4=事件环, 5=通知」，与实现（procExtraFilesForShm 只返回 memfd+evtfd）和 shmpass_unix.go 的权威注释互相矛盾。 plan.md：§13.1/13.3/13.4/13.8 的验证项按实测打勾，并注明证据（提交号 / 测试名 / 实测数字），不留无依据的勾。	2026-09-10 21:18:16 +08:00
JianFeeeee	2572688c51	proc: 性能基准 + 流式压测（Part 6.6 验收项）此前只做了功能冒烟与内存快照，延迟与压测都没测。这两项是计划里明确列出的验收条件，补上。 ## 基准结果（AMD Ryzen 7 7840HS） \| 项目 \| 实测 \| 基线 \| \|---\|---\|---\| \| 工具调用 RPC 往返 \| 24.1 µs \| 实验 11: 19.6 µs（同量级） \| \| 锁仲裁（内核侧） \| 0.76 µs \| 见下注 \| \| 事件环写入 \| 95 ns \| — \| \| 事件环并发写入 \| 83 ns \| 无锁竞争恶化 \| \| 完整 stage 往返 \| 132 µs \| 含 3 次进程间往返 \| \| 共享段编解码 \| 3.7 µs \| 占 stage 的 2.8% \| 锁仲裁 0.76µs 不可与实验 3 的 19.40µs 对照——测的不是同一个东西：实验 3 测插件经 RPC 请求锁的完整跨进程往返，本基准只测内核侧 lockRegistry.acquire/release。真实成本仍在 20µs 量级。基准原名 BenchmarkStageLockRoundTrip 有误导性，已改为 BenchmarkStageLockArbitration，并在注释里写明不可对照的理由—— 否则日后有人拿 0.76µs 去比 19.4µs 会得出「优化了 25 倍」的错误结论。 stage 往返 132µs 的成本构成：共享段编解码只占 3.7µs，其余是一次 stage 要走 3 次进程间往返（stage.invoke + 插件侧反向的 stage.lock / stage.unlock）。相对 LLM 往返 2-8 秒可忽略；要优化的方向是把 lock/unlock 合入 stage.invoke 的请求/应答，省掉两次往返。 ## 流式压测：§4.3 标记「风险高」的那一项通过原文担忧：「Bus.Publish 路径禁用任何锁/阻塞——流式输出逐 token 发布，任何等待都会卡顿」。事件环是 Part 5 新加在这条路径上的，必须验。 ``` 5000 次 Publish + 每条睡 20µs 的慢消费者实测 2.29ms，均摊 457 ns/token 同步语义理论下限 100ms 订阅者 1 个：1.547ms（515 ns/次）订阅者 8 个：1.518ms（506 ns/次） ← 无线性恶化环溢出（无消费者写 30000 次，cap=8192）：均摊 35 ns/次 ← 仍 O(1) ``` 2.29ms 与实验 4 的数字完全一致（那次也是 2.29ms / 0.46µs per token）， post-and-forget 在实现中成立。第三项的意义：消费者完全停摆时写端覆盖最旧 slot，这条路径仍是 O(1)，故「消费者卡住」不会连带拖慢内核主循环。 Ref: docs/zh/plugin-migration-plan.md Part 6.6、docs/zh/架构迁移评估.md §4.3	2026-09-02 21:42:18 +08:00

Author

SHA1

Message

Date

JianFeeeee

b71a88a471

chore(shm): 补齐 §13 验证项，删除统一区域遗留死代码

三件事，都是 plan.md §13 里未打勾的项：

1. §13.3「Bench: ToolInvoke 延迟对比」补测（bench_test.go）
   改造后原有的 BenchmarkToolInvoke 仍走 legacy 内联 Args，已不代表生产
   路径。拆成 inline / frame 两个子基准并各测两个尺寸（-count=3 取中位）：

     payload      inline（RPC 报文）   frame（共享内存帧）   差
     16 B          26.4 µs/op           48.0 µs/op        +21.6 µs
     32 KiB       695.6 µs/op          391.7 µs/op       −303.9 µs

   取舍随尺寸翻转：小 payload 多付 ~22µs 帧固定开销，大 payload 省掉整份
   JSON 编解码与管道拷贝、快 44%。因为线上工具结果动辄几十 KB 且 22µs
   相对 LLM 往返 2-8 秒可忽略，所以统一走帧而不按大小分叉（§13.3 第 4 条）
   是对的。

2. 删除 §13.1 遗留死代码（evtring.go）
   allocEvtRing 自统一共享区域之后从未被调用——旧版它单独建 memfd + eventfd，
   现在只有一个 memfd，事件环只是区内的一个 segment（NewEvtRing 操作区内
   切片）。留着会让人误以为事件环还有独立段。

3. 修正误导性注释（plugin.go）
   仍写着旧 3-fd 布局「3=StageContext, 4=事件环, 5=通知」，与实现
   （procExtraFilesForShm 只返回 memfd+evtfd）和 shmpass_unix.go 的权威
   注释互相矛盾。

plan.md：§13.1/13.3/13.4/13.8 的验证项按实测打勾，并注明证据（提交号 /
测试名 / 实测数字），不留无依据的勾。

2026-09-10 21:18:16 +08:00

JianFeeeee

2572688c51

proc: 性能基准 + 流式压测（Part 6.6 验收项）

此前只做了功能冒烟与内存快照，延迟与压测都没测。这两项是计划里
明确列出的验收条件，补上。

## 基准结果（AMD Ryzen 7 7840HS）

| 项目 | 实测 | 基线 |
|---|---|---|
| 工具调用 RPC 往返 | 24.1 µs | 实验 11: 19.6 µs（同量级） |
| 锁仲裁（内核侧） | 0.76 µs | 见下注 |
| 事件环写入 | 95 ns | — |
| 事件环并发写入 | 83 ns | 无锁竞争恶化 |
| 完整 stage 往返 | 132 µs | 含 3 次进程间往返 |
| 共享段编解码 | 3.7 µs | 占 stage 的 2.8% |

**锁仲裁 0.76µs 不可与实验 3 的 19.40µs 对照**——测的不是同一个东西：
实验 3 测插件经 RPC 请求锁的完整跨进程往返，本基准只测内核侧
lockRegistry.acquire/release。真实成本仍在 20µs 量级。
基准原名 BenchmarkStageLockRoundTrip 有误导性，已改为
BenchmarkStageLockArbitration，并在注释里写明不可对照的理由——
否则日后有人拿 0.76µs 去比 19.4µs 会得出「优化了 25 倍」的错误结论。

**stage 往返 132µs 的成本构成**：共享段编解码只占 3.7µs，其余是
一次 stage 要走 3 次进程间往返（stage.invoke + 插件侧反向的
stage.lock / stage.unlock）。相对 LLM 往返 2-8 秒可忽略；要优化的方向是
把 lock/unlock 合入 stage.invoke 的请求/应答，省掉两次往返。

## 流式压测：§4.3 标记「风险高」的那一项通过

原文担忧：「Bus.Publish 路径禁用任何锁/阻塞——流式输出逐 token 发布，
任何等待都会卡顿」。事件环是 Part 5 新加在这条路径上的，必须验。

```
5000 次 Publish + 每条睡 20µs 的慢消费者
  实测 2.29ms，均摊 457 ns/token
  同步语义理论下限 100ms

订阅者 1 个：1.547ms（515 ns/次）
订阅者 8 个：1.518ms（506 ns/次）   ← 无线性恶化

环溢出（无消费者写 30000 次，cap=8192）：均摊 35 ns/次   ← 仍 O(1)
```

2.29ms 与实验 4 的数字完全一致（那次也是 2.29ms / 0.46µs per token），
post-and-forget 在实现中成立。

第三项的意义：消费者完全停摆时写端覆盖最旧 slot，这条路径仍是 O(1)，
故「消费者卡住」不会连带拖慢内核主循环。

Ref: docs/zh/plugin-migration-plan.md Part 6.6、docs/zh/架构迁移评估.md §4.3

2026-09-02 21:42:18 +08:00

2 Commits