2-runtime IOPS 微基准：10⁸× a=a+1，kvspace-c 695.8 ns/iter（vs Python 8.6× / Rust 271×）—— 每操作 KV 往返地板价（关联 #194 #116）

[miaobyte]

结论先行

同一个 a = a + 1 循环跑 10⁸ 次，同机、shm 后端，隔离测量「每操作一次 KV 往返」的地板成本：

实现	用时	iters/s	ns/iter	vs Rust	vs Python
Rust（rustc -O，black_box 防优化）	0.257 s	389.6 M	2.57	1×	—
Python 3（原生 while）	8.052 s	12.4 M	80.5	31.4×	1×
kvspace-c（get+decode / encode+set，shm 直连）	69.58 s	1.44 M	695.8	271×	8.6×

• kvspace-c 每次迭代 = 2 次 KV 操作，吞吐上限 ≈ 2.87 M KVops/s（≈348 ns/op）。
• 695.8 ns/iter 只是 KV 层地板价：纯 C 紧循环，不含 rwir 派发、‥pc 落盘、前端 DSN dispatch、帧路径拼接、三维地址解码。真实 kvlang 的一次 a=a+1 还要叠加这些，故 prime_sieve（2-runtime/prime_sieve bench：解释执行每操作 KV 往返 → 计算密集慢 Python ~138,500×（关联 #116 寻址开销） #194）才是几十 µs/op 量级。本微基准把 2-runtime/prime_sieve bench：解释执行每操作 KV 往返 → 计算密集慢 Python ~138,500×（关联 #116 寻址开销） #194 定位的「每操作一次 KV 往返」这一正交成本单独钉死。

度量方法

• Rust：while black_box(a) < black_box(n) { a = black_box(a)+1 }，std::hint::black_box 逐次包裹阻止循环被折叠/消除；Instant 计时。rustc -O。
• Python：a=0; while a < n: a = a+1，time.perf_counter_ns()。
• kvspace-c：连 shm://，循环 kvspaceGet("a") → kvspaceDecodeHead → 读 int64 body → +1 → kvspaceNewInt64 → kvspaceSet("a")，CLOCK_MONOTONIC 计时。链 /usr/lib/libkvspace.so（前端 shm dispatch），二进制 gcc -O2。逐迭代等价于 kvlang 的 a=a+1（一次 get + 一次 set）。
• 三版均 N=100000000，末值校验 a==100000000。脚本：/tmp/iopsbench/{loop.rs,loop.py,kv.c}。

原始数据（ns/iter）：Rust 2.567；Python 80.519；kvspace-c 695.8（总 69.583 s）。

分析

• Rust→Python 的 31× 是「原生寄存器/栈」对「字节码解释 + 对象装箱」的代价。
• Python→kvspace-c 的 8.6× 是「进程内变量」变成「持久 KV 项」的代价——即便 KV 层本身已是 shm 内存态、纯 C、无网络，单次 get/set 仍要一趟 ABI + 一次 art_search + 一次 TLV 编解码。
• kvlang 当前把每一个操作数（局部 a/n、临时 rem/divisible）都当作可跨 vthread 寻址、可软链接、可崩溃恢复的 KV 项来读写——等价于 CPython 把每个 LOAD_FAST 都换成对持久化字典的 get/set。这条微基准给出该设计的单操作成本下界。

关联

• 2-runtime/prime_sieve bench：解释执行每操作 KV 往返 → 计算密集慢 Python ~138,500×（关联 #116 寻址开销） #194：prime_sieve 端到端 bench（27.3 s，三维地址版），定位「每操作一次 KV 往返 × 往返次数」。本 issue 单独量化「单次往返」这一因子。
• 2-runtime/PC 与帧寻址：调用深度导致 key 长度 O(D)、活跃 key 总量 O(D²) —— 评估 [ctlflow,irseq,params] 三维地址 #116：三维地址 [irseq,params] 减小单次往返的 key 体积（33.37 s→27.3 s，~18%），但不改变往返次数与单次 KV 地板价——本 issue 的 695.8 ns 与 key 形态正交。

后续

读写码改进方案（参考 CPython fast-locals / 值栈 / PEP 659，引入 local/stack/kv 操作数分层 + 检查点写回）见下方评论。

[miaobyte]

改进方案：分层读写码 + 检查点写回（参考 CPython）

用 CPython 的镜子看根因

本 issue 测出 Python→kvspace-c 慢 8.6×。CPython 之所以没更慢，靠的正是 kvlang 现在缺的那个区分：

• LOAD_FAST/STORE_FAST：函数局部编译期定名为整数槽（co_varnames→index），运行时只是 frame->localsplus[i] 一次数组索引，不哈希、不查字典。
• 求值栈：中间临时（rem、比较结果）压栈弹栈，从不进名字空间。
• 只有真正的全局/属性才走 LOAD_GLOBAL/LOAD_NAME 字典查找。
• PEP 659 自适应特化再给热指令加 inline cache（BINARY_OP_ADD_INT）。

kvlang 现状 = 把每个 LOAD_FAST 都换成对持久化字典的 get/set。 缺的核心区分是：哪些操作数需要跨 vthread 可见 / 可软链接寻址 / 可崩溃恢复（→ KV），哪些只是帧内纯值临时（→ 进程内槽）。 今天一律当前者。

① 操作数三分类（对齐 CPython 指令分类）

kvlang 新类	语义	落点	CPython 对应
local 快槽	帧内纯值标量，进程内数组索引，检查点才写回	vthread 执行器内存	LOAD_FAST/STORE_FAST
stack 求值栈	表达式临时，永不落 KV	vthread 执行器内存	值栈
kv	跨 vthread 共享 / 被软链接引用 / 被 watch 的量	kvspace	LOAD_GLOBAL/STORE_GLOBAL

② 归类在 layout（#202 定位阶段）做

这本就是定位阶段该干的活：一次逃逸/别名分析——把「未逃逸、未被软链接指向、未被别的 vthread watch」的裸标识符标为 local，其余 kv。槽号像 co_varnames 一样编译期定死，塞进三维地址（#116）的 params 维。保守起见：任何无法静态证明「不逃逸」的量一律降级为 kv，正确性优先。

③ runtime 侧

[d] 帧携带进程内 fast-locals 数组 + 求值栈；native 算术/比较改栈机形式（弹二压一），整个内层纯值 while 全程零 kvspace 往返。runtime-rs 现已对「连续纯 native rwir」批处理，这是把批边界从「相邻几条」扩到「整个热循环」。

④ 检查点写回 —— 与崩溃恢复对齐（唯一需谨慎处）

kvlang 立身之本是 PC/状态全落 KV → 可崩溃恢复。全进程内会丢这个保证。折中不是放弃，而是把恢复粒度做成旋钮：脏快槽仅在三处 flush（合成一次 SetBatch）——

1. 遇 ext rwir 交回上层派发（yield 点）
2. call/return 跨帧
3. 每 K 次迭代的周期检查点

崩溃后从最近检查点 PC + 已写回快照重放。可观测性从「每步可见」降为「检查点可见」，检查点频率 K 就是 恢复精度↔速度 的旋钮（K=1 退化为今天的行为）。CPython 无恢复语义，kvlang 保留它、只调粗——这是 kvlang 的取舍，不是抄 CPython 到底。

⑤ 直击 kv.get/kv.set 本身的不足（即使保留 KV 语义也该做）

• inline cache（对齐 PEP 659）：缓存上次 art_search 命中的节点指针；2-runtime/PC 与帧寻址：调用深度导致 key 长度 O(D)、活跃 key 总量 O(D²) —— 评估 [ctlflow,irseq,params] 三维地址 #116 之后键定长、命中率高，热键第二次访问跳过树查找。
• 批量写回：一个检查点内所有脏槽合并成一次 SetBatch，摊薄 ABI + 编解码固定开销。

预期收益（有上界）

热循环 KV 往返被 fast-locals 消掉后，纯值循环速度从今天的 KV 地板价（~348 ns/op）逼近 Python 字节码级（~80 ns/iter），乐观下（原生联合值免装箱）逼近 Rust 级——即 KV 受限部分 ~8.6× 到 ~271× 的空间，量级与本 issue 微基准一致。但这只压「每操作一次往返」的常数与次数，不改变 kvlang「编排层解释执行」的定位；真正的计算密集仍应下沉扩展世界（op-gpu/numpy），与本方案正交、互补。

待讨论

• 逃逸/别名分析归类规则的精确定义（软链接指向、watch 订阅如何静态发现；无法证明即降级 kv）。
• 检查点默认 K、以及是否暴露为 rwfunc 级注解。
• fast-locals 是存 XValue 还是原生联合值（后者免装箱、收益更大，但需类型确定）。