同一算法、代码逐行对齐的工作量对比。Rex 以 LLVM 最高优化级别（-O3）编译，Go 采用官方默认编译优化，各跑 3 次取最优。
测试时间：2026-08-05 · 计时使用程序内高精度时钟，不含进程启动
| 项目 | 配置 |
|---|---|
| 操作系统 | Windows 11 (Build 26200), x64 |
| CPU | AMD Zen5 桌面处理器（AMD64 Family 25 Model 117），16 逻辑核 |
| Rex | v0.1 · LLVM 编译型语言，无 GC，函数帧自动内存管理（AOT：rex build -O 3；JIT：rex run -O 3） |
| Go | go1.26.0 windows/amd64（官方 GC，GOGC=100 默认） |
| 优化级别 | 双方均为最高优化（Rex -O3；Go 默认编译优化） |
约 1.65 亿次函数调用，无内存分配、纯 CPU 计算——无 GC 的语言在此类场景下没有任何运行时开销。
结论：Rex 比 Go 快约 17~18%。LLVM -O3 生成的机器码在深层递归调用上优于 Go 编译器，且 Rex 无 GC 暂停。
数据来自专项对比报告（2026-08-05）。朴素 concat 循环拼接是 O(n²) 全量拷贝；改用 StringBuilder 后降为 O(n)，Rex 自身提速数百倍。
| 基准项 | Rex JIT | Rex AOT | Go 1.26 | 备注 |
|---|---|---|---|---|
| concat 拼接 5000 次 | 12.36 ms | 12.44 ms | 2.64 ms | O(n²) 全量拷贝，非推荐写法 |
| builder 追加 1M 次 | 627 ms* | 5.27 ms | 1.55 ms | O(n)，差距为常数倍 |
* JIT 模式下 builder 需跨越「LLVM 原生代码 → ctypes → Python bytearray」边界，单次开销约 627ns；AOT 模式无此问题。
与 Go 的差距从 concat 的 4.7 倍缩小到 AOT builder 的 3.4 倍——剩余差距来自 Go 编译器对
strings.Builder 的内联优化，属于「运行时库 / 编译器优化空间」，而非语言本质缺陷。
Rex 没有垃圾回收器：内存由函数帧自动管理、确定性释放。与「有 GC」的语言相比，换来的是可预期的行为。
客观说明：在「大批量同尺寸分配 / 回收」的分配密集场景（如 3000 次 × 20000 元素数组压力测试，约 480MB 堆分配）下， Go 的并发 GC 与 bump-pointer 分配器确实更快（约 64~66%）。Rex 单次分配的固定成本更高，换来的是上述可预期的内存行为。
| 基准项 | Rex AOT | Rex JIT | Go 1.26 |
|---|---|---|---|
| fib(40) 纯递归 | 339.2 / 335.7 / 339.9 | 342.6 / 339.2 / 338.2 | 394.7 / 397.8 / 400.5 |
| 数组压力 480MB | 108.6 / 110.5 / 107.6 | 109.0 / 110.3 / 108.8 | 66.0 / 67.5 / 65.6 |
| 字符串拼接 5000 次 | 16.0 / 14.5 / 14.6 | 13.1 / 12.4 / 14.7 | 1.55 / 1.01 / 1.51 |
| concat 拼接 5000 次 * | 12.72 / 12.59 / 12.44 | 12.36 / 12.37 / 16.03 | 3.06 / 4.30 / 2.64 |
| builder 追加 1M 次 * | 5.27 / 5.88 / 5.73 | 627.18 / 633.90 / 633.46 | 1.58 / 1.55 / 2.12 |
单位：毫秒（耗时越低越好，各跑 3 次取最优）。前 3 行来自整体对比报告；带 * 的两行来自字符串拼接专项报告。 「字符串拼接」与「concat 拼接」为同项目不同场次的数据，字符串拼接页内一律以专项报告为准。