来源时间 本站刊期
行业动态Simon Willison
parse_number() 作为 SQLite 扩展:C 与 Rust
parse_number() as a SQLite extension: C vs Rust
Simon 权衡 C/Rust SQLite 扩展:内存安全是否值得构建摩擦?
判断
打包 SQLite 扩展的开发者必须选择语言:Rust 以 298–321 KB 二进制为代价获得内存安全和现成 strtod;手写 C 快路径则以 14 KB 最小体积和每行 16–19 ns 最快速度取胜。
依据
Simon Willison 报告称,四个扩展实现相同的 parse_number() 行为,测试覆盖类型保留、解析规则和浮点精度,且所有版本在 800 万次 fuzz 检查中一致。产物大小:Rust 使用 Rusqlite 为 321 KB,使用 sqlite-loadable-rs 为 298 KB,而 C 为 14 KB。200 万行上的每行净成本,越低越好:首个 C 版本在混合数据上为 67 ns,纯整数为 25 ns,纯小数为 106 ns,因为它依赖 strtod();在他要求自定义十进制解析器后,新 C 达到 19 ns、16 ns 和 18 ns。Rusqlite 为 46/36/55 ns,sqlite-loadable 为 41/32/47 ns。机制:C 的 strtod 比 Rust 的等效实现大约慢一倍,因此尽管产物更大,Rust 起初更快——自定义 C 快路径弥合了这一差距。
- 首个 C67 ns
- 新 C19 ns
- Rusqlite46 ns
- sqlite-loadable41 ns
没写清 文章从未报告构建摩擦:没有编译时间、交叉编译设置,也没有说明快路径额外增加多少 C 代码需要维护。
下一步 查看链接的 simonw/research 报告中新 C 快路径源码,再在第二套工具链上重跑基准,以确认 16–19 ns 数字仍成立。