mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-09-26 12:23:23 +00:00
5ccdf24f18
codec.go 的注释写着「EstimateTokens 是否该留在 C 侧由 codec_bench_test.go 的实测数据决定，不要凭直觉断言」，但那个文件此前并不存在（悬空引用）。 plan.md 与设计文档也都在说「需先有真实延迟基线（当前没有）」。本提交把它补上。 ## 数据（ns/op，benchmem） | 基准 | C（经 cgo）| 纯 Go | 谁快 | |---|---:|---:|---| | ModelContextWindow（短 ASCII）| 175 | 38 | Go 快 4.6× | | EstimateTokens / 空串 | 100 | 0.43 | Go 快 230× | | EstimateTokens / 短 ASCII | 115 | 6.5 | Go 快 17× | | EstimateTokens / 短中文 | 100 | 29 | Go 快 3.4× | | EstimateTokens / 中 200 字 | 229 | 509 | C 快 2.2× | | EstimateTokens / 1KB 中文 | 840 | 2870 | C 快 3.4× | | EstimateTokens / 1KB ASCII | 2318 | 332 | Go 快 7× | | TruncateByTokens / 短中文 | 233 | 54 | Go 快 4.3× | | TruncateByTokens / 1KB 中文 | 3923 | 6918 | C 快 1.8× | （已用 -count 复测确认稳定；ascii_1k 的异常已单独隔离复测 3 次） ## 三条结论 1. **cgo 固定开销约 95–100 ns/次**，小输入下完全压倒算法差异。 2. C 只在**长中文**（UTF-8 步进重）上领先；长 ASCII 反而 Go 快 7× （Go 的 utf8.RuneCountInString 对 ASCII 有快路径，C 侧逐字节跑）。 3. ⇒ 判据应是「哪个在**真实输入分布**下真能变快」，不是「哪个看起来更底层」。 ## 对后续 C 化的影响（已写进 plan.md §七 与设计文档 §7.1） - EstimateTokens 的真高频点在 process.go:476 的逐事件循环与 resident.go:552。 字段分布不单一：Source 是短标签（Go 快 17× 那一档）， Input/Response 是对话文本（长中文 C 快、短文本与长 ASCII Go 快）。 ⇒ 当前一刀切走 C 会让短串净亏；正确做法是按长度分派， 但须先用真实长度分布复测，不要凭推测动手。 - ModelContextWindow（provider.go:333）与 TruncateByTokens（tooldefs.go:38） 调用点单一、非热路径，开销在单次请求尺度上无关痛痒。 这不否定 C 化方向：协议编解码（JSON 解析、SSE 分片）处理长文本， 才是 C 的主场，也是比「把短函数搬过去」更合理的下一步。