perf: post-optimization benchmark/profile findings and next priorities (Map, arrays, property writes)

[Eric-Song-Nop]

This follow-up investigation identifies the next performance priorities after the optimizations tracked in #6, #7, #8, #9 and #10, building on the profiling work in #4.

本轮建议优先处理 Map 查找、真实数组的键处理、已有属性槽更新。证据主要指向多余的扫描、复制、字符串转换和布局发布；这些应先于更大范围的 VM/调用协议重构逐项验证。

被测版本与方法 / Measurement scope

• 被测快照：Eric-Song-Nop/quickjs-oxide@cdc35ec，包含静态属性 Atom、非数组提前返回、原始数值转换、引用清理和内建批量初始化等已有优化。发 issue 时该快照比上游 main 56faa471a5f923ef0fe9540e0b12f64b1e7ec6c5 多 38 个提交；本文数字属于这个优化后的快照，不是未经这些改动的上游 main。
• 机器：eric-83am，AMD Ryzen 7 7840HS，Linux 6.18.44-1-lts；Rust 1.94.1 / LLVM 21.1.8。主要 timing/stat/CPU 采样固定 CPU 2，SMT sibling 为 CPU 3；未锁频或隔离整台机器。构建与正式测量分开串行执行。
• 普通 timing binary：release、debug=1、strip=none，profiling feature 关闭。另建 profiling binary，以及强制 frame pointer 的采样 binary；CPU 比例来自采样构建，墙钟 benchmark 来自普通构建。
• 参考：QuickJS 2026-06-04，GCC 16.2.1、默认 make 的 -O2。测量后独立重建的 .text/.rodata/.data/.data.rel.ro 与被测参考 ELF 逐字节相同。V8-v7 外部源码固定在 ahaoboy/js-engine-benchmark@2034d98fc8c5f8044e186267593f5d5ea5232caf。
• 覆盖 50 项固定 microbench、全部 8 项固定 V8 子套件、8 个 Map 规模配置、10 个对象宽度/构建对照配置；另保留原始 V8 单轮筛查和默认五项 microbench 三轮。
• microbench 抽取原始函数体及必要 helper；单独 pilot 后固定相同 N，两引擎每轮交错运行，各三轮。四项首次过短的转换负载另以 N=500000、五轮重测并替换汇总。固定 V8 保留 base/suite 原文和原断言，执行一次 Setup/run/TearDown，各三轮。原始自校准 harness 另行运行。
• 固定工作负载全部正式样本成功，完整可观测 stdout 在两引擎间一致；这只是 workload smoke check，不替代 Test262。

Benchmark：当前还差多少

以下均为 整进程墙钟中位数，单位 ms，包含启动、编译、输出和收尾；比例为 Oxide/QuickJS，越大表示 Oxide 越慢。它不是上游 ns/op、不是纯执行阶段时间，也不是预计能取得的加速倍数。* 表示 QuickJS 进程短于 20 ms，启动与调度影响不可忽略。

Case	固定 N	Oxide ms	QuickJS ms	慢倍数
empty_loop	6084891	941.337	28.004	33.6×
prop_read	846083	962.523	23.904	40.3×
prop_write	314880	988.454	10.025	98.6× *
array_read	258984	974.331	15.199	64.1× *
array_write	62914	1018.251	6.412	158.8× *
array_slice	872	934.589	14.383	65.0× *
typed_array_read	136651	964.113	13.486	71.5× *
arguments_read	19199	1005.923	10.039	100.2× *
func_call	400000	814.395	29.778	27.3×
bigint64_arith	1600	629.182	47.314	13.3×
map_set_string	10	1022.977	4.225	242.1× *
map_set_int	22	946.043	4.220	224.2× *
regexp_ascii	113	975.183	16.314	59.8× *
string_build_large1	80	460.992	67.594	6.8×

CPU profile：时间花在哪里

共 86 份采用的 profile、70,835 个样本、0 个 lost-event records。使用 cycles:u、499 Hz、frame pointers，最终以匹配 ELF/libc 符号和 perf script --no-inline --max-stack 512 解码。下表 12 项关键 microbench 均为三次 profile 的 period 加权结果。包含子调用的比例互相重叠，不能相加。

Case	样本数	热点	包含子调用 %
empty_loop	1552	read_frame_binding	20.50%
empty_loop	1552	execute_hot_instruction	52.19%
prop_write	1538	prepare_set_property_with_receiver_in_realm	66.77%
array_write	1668	intern_property_key	47.87%
array_slice	1614	intern_property_key	66.87%
typed_array_read	1526	typed_array_canonical_numeric_index	40.40%
arguments_read	1562	create_arguments	74.12%
arguments_read	1562	replace_layout	51.81%
map_set_int	1495	find_map_record	94.79%
map_set_string	1840	find_map_record	96.83%
regexp_ascii	1523	replace_layout	26.45%
func_call	1282	snapshot_function_bytecode	4.04%

普通构建的硬件计数也表明存在大量额外工作：同一固定工作量下，Oxide 的 retired instructions 分别约为 QuickJS 的 20.6×（空循环）、102.8×（属性写入）、261.3×（数组写入）、414.5×（字符串键 Map）。数组写入 IPC 为 3.07 / 2.92，不能把其差距主要归结为 IPC 不足。

两个规模实验：避免只盯单个固定尺寸

Map 每个配置累计 32768 次 set + 32768 次 has，仅改变每个 Map 的容量及 Map 数量。三轮中位数，单位 ms；校验和均为 32768。

容量	整数键 Oxide / QuickJS	字符串键 Oxide / QuickJS
32	115.64 / 5.39	188.15 / 7.21
128	243.33 / 5.87	433.04 / 7.40
512	795.05 / 5.42	1612.88 / 6.72
2048	2825.61 / 4.82	5083.62 / 7.56

同样写已有属性 p0 十万次，改变对象的总属性数。另做相同对象创建和输出、但没有写循环的构建对照。以下仍是直接测得的全进程时间，没有扣除启动时间后冒充独立阶段测量。

属性数	含写循环 Oxide / QuickJS ms	仅构建 Oxide / QuickJS ms
8	96.68 / 3.34	4.21 / 1.67
32	112.43 / 3.35	4.42 / 1.73
128	177.33 / 3.35	5.42 / 1.75
512	411.22 / 3.25	6.04 / 1.77
2048	1352.78 / 2.88	11.47 / 2.23

建议拆开的九个优化点 / Proposed follow-ups

1. P0 · Map 索引与快照（find_map_record）：每次先收集并复制全部存活记录，再逐项 root 和 SameValueZero 比较。先删除整表临时 Vec，再引入指向保序记录的哈希索引；只去掉 Vec 仍不能解决线性查找。保留 NaN/±0、字符串/BigInt 相等性、对象身份、删除后重加顺序、活迭代器与 GC 语义。

2. P0 · Array 数字索引与固定键（array_own_key）：之前的提前返回解决的是非数组。真数组仍先 intern length 再识别 index，slice 等内建也存在整数→字符串→intern。让立即整数 Atom 先返回，并复用运行时固定键；保留洞、稀疏数组、原型 setter、只读 length 和索引上界。

3. P0 · 已有槽更新延迟复制（store_property_slot）：在确认 existing slot 的 flags 未变之前，就复制 entries 和 slots。将同槽同 flags 的替换放在复制之前，只有布局变化才复制；进一步考虑 receiver==object 的 own writable data 路径。保留 Proxy/accessor、异 receiver、VarRef/AutoInit、冻结属性及所有权错误契约。宽度实验与该机制一致，但尚未通过优化后的 A/B 证明它是唯一原因。

4. P1 · TypedArray canonical-index 快路径（typed_array_canonical_numeric_index）：立即整数索引仍经过 spelling→ToNumber→NumberToString→spelling comparison。可先处理已确定的非负整数 Atom，再合并无回调区间的 buffer 状态读取。注意 ta[-0] 与 ta["-0"]、非规范字符串、越界和 detached/resizable buffer；值转换可执行用户代码，之后仍需重验。

5. P1 · 平坦字符串路径（Utf16Units）：平坦短字符串也建立含 61 个 Option 槽的通用遍历状态。为 Latin1/UTF-16 提供直接 slice 比较、哈希与范围复制，rope 保留通用路径。V8 RegExp 中 Utf16Units::next 自身约 24.8%，replacement 的重复 skip/range 扫描也应检查。维持 surrogate、跨表示相等性与 hash/Eq 一致性。

6. P1 · Arguments / RegExp 结果批量发布（Arguments、RegExp exec）：高频新对象仍逐项安装属性、反复替换布局。复用已有“先准备、一次发布”的思想；保留 mapped arguments 别名/解除映射、strict callee、实际参数数，以及 RegExp lastIndex 转换顺序、compile 重入、groups/indices 和属性顺序。

7. P1 · VM local/值栈/dispatch（execute_inner）：原始数值转换优化后，空循环热点转向直接 binding 读取、dispatch 和 numeric update。先证明 publication/verification 已保证哪些条件，再减少重复检查和中间 Value 搬运，评估安全的直接槽/栈窗口。保留 TDZ、eval/capture、回溯 PC、suspension 与外部字节码契约。

8. P2 · 函数帧与参数存储（take_call_arguments、callee frame）：调用方 split_off 参数 Vec，callee 再 clone 参数并建立 locals、flags 和值栈。先在同步非逃逸调用中评估帧/参数存储复用；generator/async、arguments/eval、闭包逃逸和递归需要独立边界。

9. P2 · 小规模引用事务（retain_edges_transactionally）：0/1/2 条边也建立 HashMap。短输入可采用小数组预检，复杂情况保留通用路径，不能削弱重复边计数、溢出预检和发布前失败保证。固定 RayTrace/Splay 的 replace_layout 分别约占 38%/21%，表明布局成本也存在于真实程序，不仅是 Context 初始化。

三个 critical 的架构/测量流程问题

1. 局部操作被放大成全局工作。 单键查找复制全表、单槽写入复制整份布局、确定的整数索引往返字符串，这是可定位的算法与内部流程成本。应区分“不会调用用户代码的内部借用区间”和“可能重入的语义边界”，在必要的边界建立根引用，而不是到处套用完整公共 API 流程。保持 unsafe_code = "forbid"，不靠删除所有权/异常检查换性能。
2. 低分辨率 microbench 不能承担几个百分点改动的验收。 当前原始 microbench 的 Oxide 五项读数连续三次都是 200/500/400/500/400 ns，QuickJS 为 10/10/10/25/10 ns。Date.now fallback 等待下一 tick，并在约 2 ms 窗口取最小值，存在明显台阶。原始成绩保留；细粒度验收应使用足够长的固定工作量、交错重复、分布与指令数。还要注意 -T 的 coverage：本轮 Map 和 RegExp 大负载各只有 9 个 arena backing-storage 事件，不能据此认为临时 Vec 或字符串分配很少。
3. 只从能完成的 harness 取得反馈，会遗漏最慢的一半套件。 旧报告诚实记录了 timeout，但这些路径仍缺少同等深度的热点反馈。本轮四个原始 V8 harness 在 60 秒内未完成，拆成单次工作却全部完成。上游 harness 有 warmup 和至少 32 次计时调用要求；单次耗时数秒会自然放大总时长。应同时保留原始 harness 状态与所有子套件的固定工作/限时采样，不能以可完成子集推导全引擎成绩。

全部 V8 子套件：单次工作与原始筛查

固定版各三轮中位数；原始版每引擎单轮、60 秒 timeout。固定版不输出上游 score，包含 setup/compile/teardown，不能冒充 steady-state score。

Case	固定 Oxide ms	固定 QuickJS ms	慢倍数	原始 Oxide 状态
richards	134.82	4.94	27.3×	ok
deltablue	208.04	8.74	23.8×	ok
crypto	4117.14	91.52	45.0×	timeout
raytrace	1643.19	30.51	53.9×	ok
earley-boyer	3819.20	94.23	40.5×	timeout
regexp	6992.77	308.23	22.7×	timeout
splay	3935.75	398.19	9.9×	ok
navier-stokes	3724.90	59.04	63.1×	timeout

采样质量、profiler 开销与验收限制

• 深栈必须单独解释：固定 Earley-Boyer 约 75.92% 的周期权重触及 127 帧上限；原始 12 秒前缀中 Earley-Boyer 为 92.80%、Crypto 为 48.30%。这些数据适合叶函数/近端热点，不能当完整调用树。固定 Richards/DeltaBlue 只有 82/121 个样本，相邻小热点不宜精确排名。
• 初次符号路径与 inline 展开设置有问题，最终全部从保留的原始 perf data 用匹配 ELF/libc、关闭 inline 展开重新解码。旧解码不用于本文结论。一次解析验证与广泛筛查短暂重叠，关键候选另做独立重复；正式固定墙钟 benchmark 在此前已完成。
• 11 轮模式轮换的小分配负载，普通/compiled-off/dump/trace 的全进程中位数为 11.902 / 12.102 / 13.358 / 12.227 ms，相对普通为 1.000 / 1.017 / 1.122 / 1.027×。包含报告 I/O，且该独立模式实验未固定核心；不能宣称通用 VM instrumentation overhead。
• 100 次独立生命周期样本中 Context 创建中位约 1.712 ms；未用 QuickJS CPU lifecycle time 除以 Oxide wall time。
• 本轮没有修改引擎，也没有重跑全量 Test262。新 fixed-work / CPU 采集工具与既有 Python benchmark 测试共 11 项通过。实现候选仍须独立 A/B、相关语义验证与完整回归；热点比例不等于未来收益。

建议的第一批验收

• Map：去全表快照并建立索引，固定总操作数的规模曲线不再随 Map 容量近似线性增长。
• Array：数字索引热路径避免 length/string interning，覆盖写入、slice 与 Navier-Stokes。
• 已有槽写入：同 flags 快路径先于布局复制，宽度实验不再明显依赖总属性数。
• 再分别推进 TypedArray、平坦字符串、结果对象批量构建；之后评估 VM 和调用帧改动。
• 每项使用当前快照的普通构建作对照，保留所有失败/timeout/回退证据，并保持语义/所有权/字节码兼容性验证。

完整 50 项固定 microbench（ms，中位数 [min–max]）

* 标记参考进程短于 20 ms。通常每引擎三轮；四项转换采用 N=500000 的五轮追加结果。

Case	N	Oxide	QuickJS	慢倍数
empty_loop	6084891	941.337 [936.818–943.084]	28.004 [25.242–30.716]	33.6×
empty_down_loop	4922868	727.989 [719.465–757.899]	22.280 [22.173–22.572]	32.7×
prop_read	846083	962.523 [956.778–976.543]	23.904 [23.167–24.287]	40.3×
prop_write	314880	988.454 [986.772–1014.869]	10.025 [9.998–10.279]	98.6× *
prop_update	244870	984.076 [974.529–1001.705]	9.354 [9.170–10.638]	105.2× *
prop_create	16000	473.764 [464.743–475.411]	13.661 [13.342–14.824]	34.7× *
prop_clone	16000	354.274 [353.050–356.886]	15.422 [15.218–15.574]	23.0× *
prop_delete	13775	933.515 [931.566–947.708]	19.476 [19.289–20.910]	47.9× *
array_read	258984	974.331 [939.281–990.257]	15.199 [14.947–15.566]	64.1× *
array_write	62914	1018.251 [993.866–1018.615]	6.412 [5.475–6.886]	158.8× *
array_update	50862	991.071 [986.400–1016.193]	6.412 [5.367–6.542]	154.6× *
array_prop_create	429	955.775 [948.984–962.737]	5.871 [5.711–6.808]	162.8× *
array_slice	872	934.589 [929.606–942.152]	14.383 [13.640–14.607]	65.0× *
array_length_read	763569	988.487 [971.999–1012.538]	21.206 [20.980–21.212]	46.6×
array_length_decr	276	900.721 [889.720–910.088]	12.216 [12.195–12.344]	73.7× *
array_push	536	954.363 [948.038–964.242]	9.988 [9.929–11.055]	95.6× *
array_pop	357	956.865 [953.330–970.513]	12.634 [12.605–13.189]	75.7× *
typed_array_read	136651	964.113 [960.264–966.960]	13.486 [11.362–13.642]	71.5× *
typed_array_write	130706	942.938 [931.311–948.904]	15.066 [14.250–15.294]	62.6× *
arguments_read	19199	1005.923 [996.929–1012.721]	10.039 [9.968–10.179]	100.2× *
arguments_strict_read	21299	989.891 [984.626–1002.527]	9.093 [8.195–9.700]	108.9× *
global_read	800000	475.010 [474.074–491.454]	14.707 [14.498–14.808]	32.3× *
global_write	800000	513.182 [502.537–524.331]	21.557 [21.346–21.838]	23.8×
local_destruct	16000	194.053 [193.707–196.012]	6.304 [5.985–6.655]	30.8× *
global_func_call	400000	799.553 [793.922–864.780]	31.861 [31.830–33.503]	25.1×
func_call	400000	814.395 [777.952–838.658]	29.778 [29.338–30.055]	27.3×
func_closure_call	387594	971.655 [915.930–991.790]	31.075 [31.040–31.168]	31.3×
int_arith	2936	895.295 [880.068–903.705]	32.691 [30.275–32.980]	27.4×
float_arith	2318	956.662 [945.460–962.188]	29.256 [28.546–29.576]	32.7×
bigint64_arith	1600	629.182 [628.469–654.626]	47.314 [46.079–47.422]	13.3×
map_set_string	10	1022.977 [997.324–1046.565]	4.225 [4.085–4.377]	242.1× *
map_set_int	22	946.043 [943.617–1013.494]	4.220 [3.348–4.227]	224.2× *
map_delete	17	1003.507 [962.275–1019.598]	4.575 [4.382–4.849]	219.4× *
weak_map_set	320	472.549 [464.130–476.554]	20.806 [19.766–20.833]	22.7×
array_for	16000	872.099 [865.024–875.632]	17.652 [16.930–17.819]	49.4× *
array_for_in	13525	923.327 [905.315–929.677]	54.248 [53.667–54.789]	17.0×
array_for_of	8710	934.913 [925.805–944.980]	16.330 [15.777–16.743]	57.3× *
math_min	1105	910.831 [909.563–911.811]	32.099 [31.006–32.112]	28.4×
regexp_ascii	113	975.183 [961.477–1001.322]	16.314 [16.209–16.830]	59.8× *
regexp_utf16	114	978.061 [973.794–1006.473]	16.397 [16.154–16.575]	59.6× *
regexp_replace	115	958.446 [949.552–958.699]	72.638 [71.001–73.048]	13.2×
string_length	486553	927.943 [913.993–944.636]	15.154 [14.997–15.207]	61.2× *
string_build1	1600	413.676 [411.749–436.005]	28.669 [27.232–29.176]	14.4×
string_build3	1600	412.570 [410.640–420.591]	48.273 [48.176–51.337]	8.5×
string_build_large1	80	460.992 [457.152–561.467]	67.594 [67.079–71.105]	6.8×
string_build_large2	80	459.190 [449.246–464.798]	65.614 [65.536–66.535]	7.0×
int_to_string	500000	337.349 [336.992–340.163]	41.085 [39.540–43.002]	8.2×
float_to_string	500000	1637.664 [1625.477–1644.945]	248.151 [246.025–254.227]	6.6×
string_to_int	500000	201.339 [196.078–212.734]	28.860 [28.259–29.571]	7.0×
string_to_float	500000	181.219 [175.300–224.374]	44.904 [43.703–45.081]	4.0×

原始证据状态

上述 benchmark/profile 数字已直接列在 issue 中。原始 perf data/stat、ELF、stdout/stderr、完整样本、构建 receipt 和复现脚本已保留在本地与 eric-83am；原始包尚未上传 GitHub，不把本地路径当作公开下载链接。

• 文件：quickjs-oxide-broad-profile-eric-83am-2026-09-10.tar.gz（65,293,018 bytes，2751 个成员逐项验证）。
• SHA-256：84b3f5d43b74ccd57aef352a6d05f3e916019895bfda52e720e0e679400b339f。
• 不包含外部 benchmark 源码或生成的第三方 workload。新建的 fixed-work/CPU 工具与完整报告目前仍是本地工作区改动，尚未有公开提交链接。

[Eric-Song-Nop]

补充第 7 项 VM local / 值栈 / dispatch：PR #18 完成发布保证相关优化后，空循环仍有较大的指令差距。下面记录剩余执行路径的具体问题，作为后续优化入口；PR #18 的计划内代码实现完成，不代表本 issue 第 7 项整体已解决。

当前结果与采样口径

• 被测生产代码：c55d59d。PR 后续 fec7519 仅更新文档，生产源码不变。
• Rust 1.94.1 / LLVM 21.1.8，普通 release，--no-default-features，profiling feature 关闭，未设置 RUSTFLAGS；CPU 2。ELF SHA-256：e4efc4c550257d929a981d358d783acd47c5d984ad74479c04adafcc99c5ae55。
• 同一固定 empty_loop 负载，N = 6,084,891，核心为 for (j = 0; j < n; j++) {}。五轮交错硬件计数、输出校验后，中位 retired instructions：PR perf: index core data structures and reclaim dynamic storage #17 基线约 110.48 亿，PR perf(vm): reuse publication guarantees in execution #18 最终实现约 74.82 亿（减少 32.3%），QuickJS 2026-06-04 约 5.62 亿；剩余比率约 13.3×。这是包含启动、编译、输出和收尾的整进程指令数，不是纯循环指令数，也不是耗时倍数。
• 为定位剩余工作，另对最终普通二进制做了一次 perf record -e instructions:u -c 1000003 采样，用 perf report --no-children --sort symbol 查看符号自身归属；约 7 千样本，0 lost samples。它是指令事件采样，不是 issue 正文中的 cycles 包含子调用比例，两组百分比不能直接作前后比较。

最终二进制的符号归属	指令采样占比
VmActivation::execute_inner	37.27%
execute_numeric_instruction	36.45%
RuntimeVmHost::put_local	7.04%
VmActivation::pop_pair	3.88%
Runtime::value_to_boolean	3.34%
VmActivation::update_numeric	3.18%
read_frame_binding	2.07%
Value::clone	1.82%

这是单次定位采样，包含编译器内联后的归属，不能把某个符号的全部比例归因于其中一个操作，也不能把占比直接当作可获得的加速幅度。原始 perf data、计数样本和构建记录保留在本地，尚未上传为公开附件。

三个具体后续问题

1. 整数关系比较仍经过通用比较流程。

numeric_execution.rs::compare 先取出两个 Value，分别经过 ToPrimitive 的原始值检查，再进行字符串/BigInt 分类、数值转换和通用比较。整数操作数不会实际调用用户代码，但仍经过这些处理层。QuickJS 的 OP_CMP 对两个整数直接比较，在栈上写回 Bool；非整数才进入慢路。

候选：在共享关系比较拥有者中增加运行时数值标签快路，先处理确切整数对，再按证据评估其他 Number 组合。实际类型不能仅靠发布验证假定。保持 NaN、混合数值、字符串/BigInt、对象转换的顺序与异常语义，不在各 opcode 中复制完整慢路。当前自增的 updated_number / update_numeric 已经有 Int/Float 快路，不能把它误报成尚未优化。

2. 局部自增仍包含读取、数值更新和写回的多个步骤。

compiler::lower_update_expression 将标识符更新发射成读取、Inc/PostInc 类操作及对应写回。当前执行指令没有 QuickJS inc_loc 式的局部槽更新操作；后者对整数局部槽可以直接更新，溢出或其他类型走慢路。

候选：检查最终生成的循环字节码及无用结果清理，评估局部更新合并或等价的共享槽操作，减少分派和中间 Value 搬运。不要仅凭源码发射顺序断言最终字节码数量或预计收益。保留整数溢出提升、Float 表示、前缀/后缀结果、TDZ、Captured 槽、参数别名及转换回调；不为了一个负载引入第二套指令表或大量重复处理器。

3. 每条字节码都发布 PC，并验证活动帧。

execute_inner 每轮调用 update_active_bytecode_pc；其运行时实现 借用 Runtime 状态、取得栈顶活动帧、核对 token 和帧类别，再写入 PC。该代码路径确实每条指令执行，但目前没有把它的独立指令份额从 execute_inner 中分离出来，不能将上表 37.27% 全归给 PC 维护。

候选：先列出所有可能观察 PC 的边界，评估能否在异常、用户代码调用、重入、挂起和恢复等必要位置发布，或在可靠的帧作用域内减少重复查找。不能简单降低更新频率，也不能跨用户代码持有 Runtime 可变借用。它与 PR #18 已撤回的 PC checked_add 简化是不同问题，不以重做该失败实验替代分析。

与 PR #18 的关系及后续验收

PR #18 已减少重复静态绑定检查、分派层次、已发布跳转验界和局部栈检查，并补齐 eval 环境共享及捕获复用。空循环不执行 eval 或闭包创建，这些优化不会直接消除上述循环成本。剩余差距不能解释为 Rust 固有开销，也尚未被上述三项定量分解完毕。

后续应分别验证这些候选：沿用明确的模块拥有者和共享慢路，先覆盖语义及所有权边界，在实际优化提交后做固定工作量交错 A/B、instructions/cycles 和完整控制矩阵。记录无收益及回退，不能只看指令数下降就宣称耗时改善。已有例子是 PR #18 静态分支最终隔离对照：整数运算指令数下降约 1.95%，但十轮计时中位数上升约 3.15%；目标空循环则有收益。此取舍已记录在 PR 计划中。

[Eric-Song-Nop]

#19 后完整 benchmark/profile 更新（2026-09-11）

本评论作为当前性能现状和后续优先级入口，替代正文中基于旧源码的排序；正文保留为历史记录。本轮没有修改生产引擎，也没有宣称新的优化收益。

**主要结果：**固定 50 microbench + 8 V8 工作量的 580/580 样本通过；58 项各补齐三轮硬件计数和普通 ELF 叶采样。放宽原始 harness 时限后，Crypto、RegExp、Navier-Stokes 都取得有效成绩；Earley-Boyer 暴露了栈溢出，而不是超时。另有 30 项成功的 frame-pointer 调用来源诊断。下面给出完整覆盖、失败原因、14 项新优先级和复现信息。

基线、构建与测量口径

• 生产二进制：1cc51bb，即 PR #19 最终引擎。PR head c52d4dc 只增加文档，Rust 源码一致。普通 release，Rust 1.94.1 / LLVM 21.1.8，--no-default-features，profiling feature 关闭、无 RUSTFLAGS。ELF SHA-256：4221d5aed8ab9df7f5c8a6992acc6562d6760b2dde9e3376d5f23cf0b4f594a3。
• 参考：QuickJS 2026-06-04，经仓库 oracle 脚本认证源码后重新构建；GCC 16.2.1 20260810，上游 Makefile -O2，具体编译命令保留。源码包 SHA-256：b376e839b322978313d929fd20663b11ba58b75df5a46c126dd19ea2fa70ad2a；本轮参考 ELF：afbebcebecb439931fcd22beb36a99f5f7b0a725a0ab8e6cc0f27b6cb4d97169。旧缓存 ELF 已变化，未沿用其旧哈希或混合参考成绩。
• 机器：eric-83am，Ryzen 7 7840HS，Linux 6.18.44-1-lts，CPU 2；频率未锁定，仍是桌面环境。正式计时、perf record、perf stat、诊断构建分阶段串行，不与构建或测试重叠。
• 固定工作量：沿用 docs/reports/data-structure-fixed-final.json 的 58 份逐字节校验负载及确切预期输出；两引擎逐轮交错，各 5 次，共 580 样本。数字是包含启动、编译、setup、执行、校验输出和 teardown 的整进程墙钟，不是 ns/op 或上游 score。参考进程短于 20 ms 的行标 *，尤其不宜用小百分比差异推断收益。
• 硬件计数：同一普通 ELF、相同负载，每引擎各 3 次交错，共 348 样本；instructions:u,cycles:u,branches:u,branch-misses:u，均为成功输出，计数器运行比例 100%，没有采用 multiplexed 比率。
• V8 源码固定在外部仓库 commit 2034d98fc8c5f8044e186267593f5d5ea5232caf。固定版保留 base/suite 和原断言，每个 benchmark 一次 Setup/run/TearDown；原始版只按上游方式内联 load。原始独立套件时限 900 s，完整组合 1800 s，每引擎各一次；这些 score 是覆盖筛查结果，尚不是重复多轮的正式分数比较。

全部 V8：固定工作量与原始 harness

固定耗时为 5 轮中位数；指令倍数来自独立 3 轮计数。Score 越高越好，不能与固定耗时倍数混为一列。

Suite	固定 Oxide ms	固定 QuickJS ms	耗时倍数	指令倍数	原始 Oxide score / 状态	原始 Oxide 秒	原始 QuickJS score
richards	74.98	5.88	12.7×	21.2×	53.4	3.141	1332
deltablue	134.66	8.32	16.2×	21.6×	53.9	5.569	1222
crypto	2044.47	91.10	22.4×	19.4×	60.2	67.832	1326
raytrace	927.90	30.03	30.9×	26.1×	79.8	31.542	2792
earley-boyer	2592.15	94.80	27.3×	21.7×	栈溢出；无有效 score	0.197	3432
regexp	5523.26	309.27	17.9×	16.5×	33.8	91.623	625
splay	3393.92	407.89	8.3×	13.0×	246.0	6.447	4885
navier-stokes	1721.97	59.08	29.1×	26.1×	97.8	50.246	2939

完整原始组合：Oxide 256.44 s 后正常退出，但包含 EarleyBoyer 栈溢出并缺少 aggregate Score，故判为失败；其余七项输出全部保留。QuickJS 30.02 s，完整 score 1885。不能拿七项子集推导 Oxide 总分。

Earley-Boyer：从“超时缺数据”变成可复现的栈预算问题

默认 #19 独立 harness 报 EarleyBoyer: InternalError: stack overflow，退出码却为 0；runner 因缺少 suite/aggregate score 正确拒绝。随后 #18 和 #19 各追加 3 次均复现，约 0.2 s 即失败，因此不是本轮发现后就能归因于 #19 的回归。固定一次工作量在普通 #19 上仍 5/5 成功，说明只测固定版会遗漏 harness 调用栈条件。

进一步在 git archive 1cc51bb 的独立源码副本中，只将 release 的 HOST_STACK_BUDGET_BYTES 从 1 MiB 改为 4 MiB；普通 release 工具链/选项与生产构建相同。未修改外部 benchmark body、warmup、32 次最低计时调用或输出要求。结果：

配置	结果	墙钟秒	Score
pr19-budget4MiB	ok	88.212	113
quickjs-budget4MiB	ok	6.261	3426

这支持“默认内部栈预算与原生调用帧占用限制了该工作负载”的判断。4 MiB Oxide 是修改了预算的诊断构建，QuickJS 明确使用 --stack-size 4M；这两行不混入上面的默认结果、不补算默认组合总分，也没有把放宽预算提交到生产代码。后续应降低 native frame 消耗并明确可支持的调用深度，而不是静默删掉溢出保护。

新 profile 的直接证据

下面是最终采用的普通生产 ELF 的三轮周期加权叶归属。带 frame pointer 的包含子调用证据单独列在后面。

负载	叶函数 / 路径	周期占比
empty_loop	execute_numeric_instruction	38.44%
empty_loop	execute_inner	33.11%
empty_loop	value_to_boolean	3.69%
v8-crypto	::to_numeric	9.04%
v8-navier-stokes	execute_numeric_instruction	8.73%
array_write	dense_array_index_value	7.88%
array_write	get_own_property_in_operation	7.20%
array_write	define_array_index	6.86%
prop_create	core::hash::sip	17.21%
prop_create	hash_one	8.22%
func_call	release_raw_no_drain	9.68%
func_call	execute_bytecode_callable	5.80%
string_length	drop_in_place<quickjs_oxide::engine::value::primitive::Utf16Units>	8.47%
v8-regexp	Utf16Units as core::iter	29.81%
v8-regexp	execute_with_interrupt	6.35%
v8-regexp	validate_program	1.06%
typed_array_write	typed_array_snapshot	5.44%
typed_array_write	snapshot_buffer_access_raw	8.02%

独立 FP 构建来自同一 1cc51bb，Rust 1.94.1，增加 -C force-frame-pointers=yes 和 debug info，profiling feature 仍关闭。它只用于确认调用来源，不能把它的百分比、耗时当作普通 ELF 的 A/B 结果：

FP 诊断负载	包含子调用路径	约占周期
string_length	intern_property_key	38.8%
array_write	define_array_index / array_length_state_if_genuine / intern_property_key	47.7% / 24.3% / 18.0%
array_slice	define_array_index / intern_property_key	56.7% / 29.8%
v8-regexp	builtin_regexp_exec / append_range	42.7% / 14.9%
prop_create	replace_layout / get_or_create_shape	36.0% / 15.2%
v8-raytrace	replace_layout	16.1%
v8-splay	replace_layout	21.7%
func_call	apply_deferred_operation / bytecode_for_callable	12.3% / 8.6%

这些父子路径存在包含关系，不能相加。例如 Array 的 length intern 也是 define_array_index 成本的一部分；缩减重复静态 Atom 工作与改写整个 Array Set 的收益也不能分别估算后相加。

新一轮优化与问题清单（按当前优先级排序）

以下是候选顺序，不是收益承诺。周期百分比是函数自身归属，包含编译器内联影响；父子函数比例不能相加，也不能直接换算为可获得的加速。每一项都要求独立提交后的交错 A/B 和语义回归。

1. P0 · 普通 JS 调用消耗过多原生栈，阻止原始 Earley-Boyer 完成。 默认发布版在完整原始 harness 中触发可捕获的 InternalError: stack overflow，而相同 benchmark body 的固定版本能完成。原始 harness 的额外调用层次已经影响可运行范围。入口：native_stack.rs:22、execute_bytecode_callable。优先缩小热调用帧、移出冷分支和大型临时值，再评估显式 VM 调用帧/循环驱动。增大内部预算只作诊断，不能作为默认引擎已经通过的证据。验收同时覆盖原始 Earley-Boyer、有限递归、小栈线程、可捕获的无限递归及 JS→native→JS 重入。

2. P0 · 内置静态名字仍反复构造字符串并 intern。 string_length 采样出现 UTF-16 iterator 析构、字符串创建、memcpy/memmove 和 get_string_property_with_receiver；读取 length 每次调用 intern_property_key("length")。此外 array_length_state_if_genuine 在判断是否为 Array 之前就 intern 同一个 length。FP 诊断中，intern_property_key 的包含子调用比例在 string_length / array_write / array_slice 分别约为 38.8% / 18.0% / 29.8%，不与普通 ELF 的叶比例混算。Array pop 的索引还有 to_string()→intern 路径。入口：Array length 状态、String 属性读取、Array pop。复用运行时已有/明确拥有的静态 Atom，已知数字索引走 property_key_for_index。这与已经完成的字节码静态 Atom 链接不同。验证未知属性、Symbol、字符串索引及原型 getter，避免跨 Runtime 缓存 Atom。

3. P0 · Dense Array 已有元素 Set 仍往返完整 descriptor 与多次 length/slot 查询。 array_write 自身热点包含 dense_array_index_value、get_own_property_in_operation、define_array_index，Navier-Stokes 也命中这些路径。perf(object): share ordinary property access and slot transactions #19 优化了 Array 读取，尚未将其特殊写入改成普通对象那样的单次定位事务。入口：define_array_index、ordinary Set 特殊回退。为 genuine dense、已有 CWE 元素、同 receiver 的赋值集中建立快路，复用保留/替换/清理事务。覆盖洞、原型 setter、不同 receiver、冻结属性、非 writable length、稀疏/大索引及错误后的已完成写入。

4. P0 · RegExp 字符串读取与 replacement 范围追加仍使用通用逐字符遍历。 V8 RegExp 的 Utf16Units::next 仍是最大叶热点。ReplacementStringBuffer::append_range 为检测宽度和追加内容分别建立迭代器，执行 skip(start)，晚位置小范围可能反复扫描前缀；builtin exec 还把输入收集为 UTF-16 Vec。入口：append_range、builtin_regexp_exec。优先提供共享 flat range / 只读输入视图，减少前缀扫描和重复 materialization。perf: index core data structures and reclaim dynamic storage #17 的 flat equality/hash 已完成，这里是尚存的消费路径。验收晚位置多次替换、Latin1/UTF-16/rope、孤立 surrogate、零长度匹配、replacement 回调和输出宽度语义。

5. P0 · 运行时 Number 标签的算术、位运算和关系比较仍经过通用数值流程。 空循环主要落在 numeric dispatch；Crypto 的 to_numeric、Navier-Stokes 的数值路径也有直接采样证据。入口：compare、binary_numeric。先做确切 Int 对的比较与位运算，再隔离评估其他 Number 组合，减少中间 NumericValue 搬运及 Int→f64→Int。原始值绕过 host ToPrimitive 和 Number 自增快路已经存在，不能重复报功。保留 NaN、负零、溢出、移位掩码、BigInt 混合错误和对象转换顺序。

6. P1 · 小对象创建仍反复复制和哈希整份 shape fingerprint。 prop_create 的 SipHash/hash_one 很突出，RayTrace 和 Splay 同样出现哈希、布局及分配成本。入口：get_or_create_shape、store_property_slot。已有槽替换已解决；新字段走共享小 shape 时仍构造完整 fingerprint，且克隆 slots。候选是有界的 (原 shape, atom, flags) transition 缓存或对确实私有的新对象批量发布。保留 shape 共享、弱缓存回收、Symbol 所有权、属性顺序及 computed key/初始化表达式回调；不得把所有哈希成本都归给 shape。

7. P1 · 每次函数调用的 callee 存储、元数据取得和 root 生命周期仍昂贵。 func_call 中 release_raw_no_drain、execute_bytecode_callable、snapshot_function_bytecode、bytecode_for_callable 都有叶样本。入口：建帧、callable 元数据。caller 参数窗口已经借用，callee 仍分配 arguments、locals、capture 标记并取得多份 owning handle。先区分必要 roots 与短无回调区间的重复保活，再评估同步不逃逸调用的存储复用。与第 1 项相关，但验收目标是调用吞吐和分配次数；generator/async、arguments/eval、捕获、异常及跨 realm 必须保留独立边界。

8. P1 · Array slice/push/pop 等内置操作仍逐元素经过通用属性语义。 slice 的 try_get_array_like_index、length 查询、dense 读取和 define 占据多处热点；push/pop 也包含键构造和通用 Get/Set/Delete。入口：slice、push。第 3 项降低单次写入，这一项减少可证明无回调连续区间的调用次数、重复边界查询和目标数组逐项发布。species、holes、Proxy、原型访问器、长度/参数转换及中途异常使得整操作不能无条件批量化；优先 genuine dense + 默认 species 的受保护情况。

9. P1 · 局部变量自增仍经历读槽、栈更新、写回与多次 dispatch。 空循环的 binding read、update、put_local 和 pop_pair 仍有独立样本。入口：lower_update_expression。先导出并检查最终发布字节码，再选择局部更新合并或共享槽操作；本轮没有借源码发射顺序伪造最终 opcode 数。覆盖前后缀结果、未使用结果、Int 溢出、Float、TDZ、捕获、mapped arguments 和对象转换回调；不重新实现已有 updated_number 快路。

10. P1 · 每条指令发布 PC 并重复定位/核对活动帧。 该路径在源码中逐条执行；本轮仍不能把 execute_inner 的整体叶占比归给 PC。入口：execute_inner、update_active_bytecode_pc。先枚举回溯、异常、回调、重入、挂起与恢复观察点，再评估边界发布或可靠帧作用域中的直接更新。必须先做独立诊断量化；不能简单隔几条更新，也不能以重试 perf(vm): reuse publication guarantees in execution #18 已撤回的 checked_add 实验代替此工作。

11. P2 · 同一字节码位置重复读同 shape 的普通属性仍重新分类、哈希找槽和保活。 prop_read 的 internal_get_or_missing / get_property_with_key 占比仍明显。入口：ordinary_read_probe、Shape::find。候选是 bounded、带 shape identity 验证的 own-data 访问缓存或更窄的无回调读取入口；perf(object): share ordinary property access and slot transactions #19 的 selective Get 已存在，不应再恢复 descriptor 快慢两套实现。缓存只保存可验证位置元数据，不保存过期 raw value；shape 回收、dictionary 原地修改、accessor、Proxy、原型变更与 GC 必须有失效证明。

12. P2 · RegExp 每次执行重新验证已经编译的不可变程序。 execute_with_interrupt / validate_program 每次扫描指令并分配 assertion-scope 辅助存储。V8 RegExp 中能看到 validate_program，但比例远小于字符串遍历，故不排在其前。把验证移动到所有生产构造/发布入口，以不可伪造的 validated program 契约承接执行；仍保留外来/测试构造的畸形程序拒绝和可变输入边界检查，不能直接删检查。以同一短模式重复 exec 的工作量验证收益。

13. P2 · 非 sticky RegExp 每个失败起点重新分配 AttemptState。 候选起点循环 每次调用 run_attempt，后者重新创建 captures、registers、undo、control vectors。采样支持 executor/分配路径存在，但本轮未把其中的每起点分配独立计数，列为源码确认的候选。先复用一次执行内的 scratch capacity，严格重置 capture/register/回溯状态；再考虑保守的首字符/字面前缀跳过。覆盖失败长输入、lookahead、反向引用、Unicode 起点、空匹配和中断，不承诺消除一般正则回溯复杂度。

14. P2 · TypedArray 原始数值写入仍重复取得 view 元数据、转换和访问 token。 新采样在 typed_array_write 中看到 typed_array_snapshot 和 snapshot_buffer_access_raw。入口：typed_array_set_index、write_converted_index。perf(object): share ordinary property access and slot transactions #19 已经让 bounds 与实际字节访问共用 buffer token，不能再次把它当未做项。后续只评估精确 Number、不会执行 JS 的转换区间是否能共享更多 view 状态；对象转换仍需在回调后重新取得 buffer，保留 resize/detach、SharedArrayBuffer、越界和 BigInt 语义。

与旧清单的对应关系与下一批顺序

• perf: index core data structures and reclaim dynamic storage #17 已实现 Map/Set 键索引和记录回收、dictionary/同 flags 槽替换、整数键和稀疏 Array 改进、模块/作用域/常量/源码坐标索引、flat equality/hash、Arguments/RegExp 批量发布、小引用事务、Number 栈更新以及 caller 参数借用。旧正文的这些“待办”不能继续原样使用；本评论只讨论其剩余路径。
• perf(vm): reuse publication guarantees in execution #18 已实现发布保证相关执行优化；空循环本轮仍约 7.482 billion instructions，QuickJS 约 0.562 billion，约 13.3×，与此前剩余执行问题一致。perf(object): share ordinary property access and slot transactions #19 已实现普通属性内核，并修复当时 Array/TypedArray 回退。本轮没有重新制造或合并这些旧实现。
• 建议先落一个范围小的静态 builtin Atom / Array length 状态读取优化，用 string_length、array_write、array_slice、array_push/pop 与完整矩阵验收；栈预算问题作为独立正确性/架构工作推进。随后分别做 dense Set、RegExp range/input、确切 Number 数值路径，不在一个大 PR 中把多项收益混在一起。
• 每项以当前普通 perf(object): share ordinary property access and slot transactions #19 ELF 为 A/B 基线，固定负载和输出，交错至少 5 次；敏感/回退项追加 10 次，配合独立 instructions/cycles。涉及语义的实现再跑相关 QuickJS oracle、完整回归和 Test262，不修改冻结预期掩盖差异。增加复杂度却没有可信收益的快路径应撤回。

采样质量与覆盖限制

• 初始普通 ELF 的 174 份 DWARF 采样共记录约 526,615 个样本，出现 148 个 lost samples，集中在 7 项。保留原文件，另以 per-thread、4 MiB mmap buffer 对这 7 项各重采 3 次；最终采用的 58×3 份普通叶采样 lost=0。放大多 CPU buffer 的尝试没有启动成功，保留其失败记录，不算 workload 样本。
• RSS 首次使用 Python 子进程的 wait4 会把 exec 前约 14–15 MiB 的启动下限带入小负载，已全部改用小型原生 launcher 重测。首轮仅作为排除证据保留，最终 RSS 表采用后者。
• libc 首次解码有未命名地址，最终使用与 ELF build-id 503200d7fda94a5dc6058d7e0694e5d1dcb2e372 匹配的 debug 文件重新解码；例如复制热点解析为 __memmove_avx512_unaligned_erms。旧未解析视图仍保留，但不用于最终表格。
• 普通 ELF 的 DWARF 深层调用链出现不可靠父地址，本评论只采用其叶归属。FP 31 项×3 次共 93 次运行，90 次成功；FP 下固定 Earley-Boyer 也触发栈溢出，3 次全部排除出成功负载归因。说明诊断编译选项会改变原生栈容量，不能假设 profile 构建与普通构建可运行范围相同。
• FP 的 kernel stack capture 上限为 127 帧。成功真实程序中 RayTrace 约 1.23%、Splay 约 0.61% 的样本触及上限；其他六项中的 Earley-Boyer 是失败前缀，约 67.89% 触顶，不代表完整工作量。其余成功套件未观察到触顶，但这仍不是每条调用链都完整的证明。
• 原始 V8 的 18 次筛查没有 timeout；Oxide 的 Earley-Boyer 和组合因 stack overflow/缺 aggregate score 被拒绝，其余结果完整。原始 score 各一轮，不声称分数稳定性。
• 本轮没有运行新引擎实现的 Test262，因为没有生产改动。既有 benchmark 工具测试 16/16 通过；所有 fixed/counter/RSS 输出及源/ELF 哈希独立核验。不会把 perf(object): share ordinary property access and slot transactions #19 历史 Test262 receipt 冒充本轮新跑结果。

独立峰值 RSS 观察

小型 C launcher 通过 fork/exec/wait4 对 engine 子进程取得 peak RSS，避免 Python 子进程 exec 前的内存下限污染；每引擎每负载仅一次，包含编译/setup/teardown。它不是 allocation count、存活 JS heap 大小或泄漏证据。12 个负载共 24 次均输出正确。

Case	Oxide peak MiB	QuickJS peak MiB
prop_create	10.70	4.01
array_push	10.73	3.92
func_call	10.52	4.01
regexp_replace	10.74	4.04
v8-richards	9.14	4.01
v8-deltablue	10.80	4.01
v8-crypto	11.81	4.04
v8-raytrace	10.26	4.04
v8-earley-boyer	112.50	12.13
v8-regexp	14.51	6.76
v8-splay	892.44	144.00
v8-navier-stokes	13.62	5.39

完整 50 项固定 microbench：5 轮中位数 [min–max]，ms

*：QuickJS 中位进程时间小于 20 ms；N 沿用固定 manifest，不是每行相同的操作数。

Case	N	Oxide ms	QuickJS ms	耗时倍数	指令倍数
empty_loop	6084891	500.17 [498.22–504.11]	27.52 [26.91–27.70]	18.2×	13.3×
empty_down_loop	4922868	417.98 [415.59–572.34]	27.53 [26.73–29.06]	15.2×	13.3×
prop_read	846083	640.89 [638.63–661.51]	24.87 [24.24–25.85]	25.8×	20.5×
prop_write *	314880	296.47 [290.04–315.15]	11.08 [10.43–11.41]	26.8×	30.6×
prop_update *	244870	389.90 [388.07–392.92]	11.12 [10.33–16.61]	35.1×	29.8×
prop_create *	16000	371.41 [369.22–387.04]	15.75 [15.68–17.13]	23.6×	25.0×
prop_clone *	16000	315.86 [314.75–319.32]	16.79 [16.18–17.07]	18.8×	17.0×
prop_delete	13775	385.76 [385.35–391.60]	20.65 [20.26–21.06]	18.7×	16.2×
array_read *	258984	437.01 [435.46–439.46]	17.05 [17.01–17.39]	25.6×	19.2×
array_write *	62914	453.27 [451.62–462.81]	7.74 [7.04–9.49]	58.6×	75.4×
array_update *	50862	456.04 [449.44–462.35]	7.48 [6.69–7.64]	61.0×	60.3×
array_prop_create *	429	577.95 [570.11–584.38]	8.22 [7.59–8.44]	70.3×	69.1×
array_slice *	872	378.92 [375.77–405.53]	16.05 [15.40–26.40]	23.6×	18.3×
array_length_read	763569	584.67 [575.07–588.92]	22.01 [21.56–22.49]	26.6×	21.0×
array_length_decr *	276	553.18 [545.54–560.64]	13.36 [12.94–13.98]	41.4×	38.4×
array_push *	536	616.89 [612.95–636.55]	11.71 [11.13–11.86]	52.7×	47.1×
array_pop *	357	567.52 [561.11–582.60]	14.50 [14.02–14.55]	39.1×	33.7×
typed_array_read *	136651	301.78 [300.13–311.91]	14.19 [13.50–14.23]	21.3×	18.8×
typed_array_write *	130706	250.86 [249.43–253.58]	15.88 [15.41–16.69]	15.8×	18.0×
arguments_read *	19199	352.24 [348.68–358.44]	14.82 [14.45–16.19]	23.8×	18.4×
arguments_strict_read *	21299	333.34 [332.17–337.05]	10.41 [9.91–11.49]	32.0×	31.6×
global_read *	800000	352.57 [349.82–359.02]	16.98 [16.46–18.22]	20.8×	14.8×
global_write	800000	370.34 [367.46–371.90]	22.66 [22.53–23.05]	16.3×	20.3×
local_destruct *	16000	136.62 [134.54–137.18]	7.95 [7.18–8.06]	17.2×	17.7×
global_func_call	400000	694.75 [689.23–718.72]	35.00 [33.93–37.09]	19.8×	17.5×
func_call	400000	674.06 [664.88–683.56]	30.74 [30.54–34.71]	21.9×	17.3×
func_closure_call	387594	776.88 [775.84–799.90]	32.81 [31.61–34.26]	23.7×	20.2×
int_arith	2936	581.26 [568.36–612.63]	35.66 [34.99–37.21]	16.3×	13.1×
float_arith	2318	604.53 [598.71–770.70]	30.59 [30.36–33.62]	19.8×	14.1×
bigint64_arith	1600	458.93 [455.01–460.96]	47.58 [47.16–48.07]	9.6×	5.8×
map_set_string *	10	37.78 [37.06–47.69]	5.08 [4.74–5.88]	7.4×	9.2×
map_set_int *	22	49.13 [49.03–49.65]	5.93 [5.62–5.94]	8.3×	11.5×
map_delete *	17	57.75 [56.89–59.59]	6.09 [5.90–6.78]	9.5×	10.0×
weak_map_set	320	334.04 [329.89–338.54]	21.88 [21.36–22.87]	15.3×	12.2×
array_for *	16000	398.41 [389.80–409.70]	19.59 [19.29–27.93]	20.3×	15.7×
array_for_in	13525	795.34 [785.13–798.95]	55.68 [54.75–55.79]	14.3×	10.1×
array_for_of *	8710	548.66 [546.20–574.46]	18.01 [17.42–19.12]	30.5×	20.7×
math_min	1105	750.95 [747.71–753.07]	34.63 [34.13–35.20]	21.7×	18.6×
regexp_ascii *	113	414.49 [412.58–417.66]	17.87 [17.71–20.63]	23.2×	16.1×
regexp_utf16 *	114	418.71 [413.58–425.42]	18.37 [17.76–18.97]	22.8×	15.2×
regexp_replace	115	782.93 [774.61–792.64]	72.44 [72.24–75.80]	10.8×	8.5×
string_length *	486553	594.61 [591.00–664.44]	15.86 [15.75–16.49]	37.5×	27.7×
string_build1	1600	287.64 [286.90–292.54]	30.72 [30.09–31.18]	9.4×	8.0×
string_build3	1600	299.70 [296.10–303.29]	51.03 [50.52–52.93]	5.9×	4.1×
string_build_large1	80	312.94 [308.29–396.87]	65.16 [63.96–67.04]	4.8×	3.6×
string_build_large2	80	320.39 [314.82–363.24]	61.24 [59.76–62.93]	5.2×	3.7×
int_to_string	500000	281.37 [276.26–312.94]	44.74 [44.48–46.32]	6.3×	4.8×
float_to_string	500000	1615.15 [1560.19–1650.36]	245.15 [244.83–247.66]	6.6×	5.3×
string_to_int	500000	159.37 [157.21–206.95]	30.50 [29.89–33.09]	5.2×	3.3×
string_to_float	500000	141.52 [131.09–159.56]	46.27 [45.98–46.90]	3.1×	2.2×

全部 58 项普通 ELF 叶热点前三（最终三轮周期加权，函数名缩写）

同名短函数的完整 Rust symbol、每轮样本和占比在原始报告中保留；这里用于扫视分布，不将父调用混入叶百分比。

Case	第 1 叶热点	第 2 叶热点	第 3 叶热点
empty_loop	execute_numeric_instruction 38.4%	execute_inner 33.1%	value_to_boolean 3.7%
empty_down_loop	execute_inner 41.7%	execute_numeric_instruction 34.6%	value_to_boolean 3.9%
prop_read	execute_numeric_instruction 17.9%	internal_get_or_missing 16.7%	execute_inner 15.0%
prop_write	execute_inner 14.1%	replace_retained_object_slot 9.4%	ordinary_set_probe 8.8%
prop_update	execute_inner 10.2%	execute_numeric_instruction 9.1%	execute_hot_instruction 7.3%
prop_create	SipHash::write 17.2%	hash_one 8.2%	__memmove_avx512_unaligned_erms 7.5%
prop_clone	SipHash::write 19.3%	__memmove_avx512_unaligned_erms 10.2%	hash_one 8.6%
prop_delete	SipHash::write 16.9%	hash_one 9.3%	__memmove_avx512_unaligned_erms 6.7%
array_read	execute_inner 18.6%	execute_numeric_instruction 16.2%	internal_get_or_missing 11.5%
array_write	dense_array_index_value 7.9%	get_own_property_in_operation 7.2%	define_array_index 6.9%
array_update	define_array_index 6.3%	dense_array_index_value 6.1%	get_own_property_in_operation 5.4%
array_prop_create	internal_set 5.6%	hash_one 5.2%	execute_inner 4.8%
array_slice	try_get_array_like_index 8.3%	array_length_state_if_genuine 5.6%	dense_array_index_value 5.6%
array_length_read	execute_numeric_instruction 20.2%	execute_inner 15.4%	internal_get_or_missing 15.2%
array_length_decr	__memmove_avx512_unaligned_erms 7.8%	drop<Utf16Units> 6.0%	array_length_state_if_genuine 3.7%
array_push	hash_one 5.0%	__memmove_avx512_unaligned_erms 4.7%	internal_get_or_missing 3.8%
array_pop	__memmove_avx512_unaligned_erms 8.8%	drop<Utf16Units> 5.0%	internal_get_or_missing 4.1%
typed_array_read	execute_inner 14.1%	execute_numeric_instruction 11.9%	internal_get_or_missing 8.6%
typed_array_write	execute_inner 15.2%	internal_set 8.7%	execute_hot_instruction 8.6%
arguments_read	__memmove_avx512_unaligned_erms 19.5%	SipHash::write 12.6%	hash_one 4.7%
arguments_strict_read	SipHash::write 13.1%	__memmove_avx512_unaligned_erms 12.6%	hash_one 5.1%
global_read	execute_numeric_instruction 35.3%	execute_inner 19.3%	get_global_var 13.6%
global_write	replace_var_ref_value 23.3%	execute_inner 21.1%	put_global_var 12.4%
local_destruct	__memmove_avx512_unaligned_erms 9.0%	internal_get_or_missing 7.2%	execute_inner 4.1%
global_func_call	execute_inner 9.3%	__memmove_avx512_unaligned_erms 8.8%	release_raw_no_drain 8.6%
func_call	execute_inner 11.0%	release_raw_no_drain 9.7%	__memmove_avx512_unaligned_erms 9.5%
func_closure_call	execute_inner 12.6%	release_raw_no_drain 9.0%	__memmove_avx512_unaligned_erms 8.7%
int_arith	execute_inner 30.4%	execute_numeric_instruction 27.5%	to_numeric 10.4%
float_arith	execute_inner 30.1%	execute_numeric_instruction 29.9%	to_numeric 8.7%
bigint64_arith	execute_inner 34.3%	execute_numeric_instruction 28.1%	push_mut 7.2%
map_set_string	internal_get_or_missing 5.0%	hash_one 3.7%	__memmove_avx512_unaligned_erms 3.5%
map_set_int	execute_inner 6.9%	internal_get_or_missing 4.3%	hash_one 4.2%
map_delete	internal_get_or_missing 4.7%	execute_inner 4.1%	get_global_var 3.2%
weak_map_set	internal_get_or_missing 7.8%	execute_inner 7.1%	hash_one 5.5%
array_for	execute_numeric_instruction 22.1%	execute_inner 21.5%	internal_get_or_missing 7.5%
array_for_in	__memmove_avx512_unaligned_erms 14.0%	execute_inner 9.9%	drop<Utf16Units> 6.4%
array_for_of	internal_get_or_missing 9.3%	call_array_iterator_next_raw 7.2%	execute_inner 6.3%
math_min	execute_inner 9.4%	internal_get_or_missing 8.8%	execute_numeric_instruction 4.5%
regexp_ascii	__memmove_avx512_unaligned_erms 15.6%	SipHash::write 4.1%	malloc 3.2%
regexp_utf16	__memmove_avx512_unaligned_erms 15.0%	SipHash::write 4.0%	drop<Utf16Units> 3.8%
regexp_replace	execute_with_interrupt 12.2%	__memmove_avx512_unaligned_erms 8.3%	Utf16Units::next 6.1%
string_length	execute_numeric_instruction 10.2%	execute_inner 9.9%	drop<Utf16Units> 8.5%
string_build1	execute_inner 33.6%	execute_numeric_instruction 26.9%	flat_concat 6.1%
string_build3	execute_inner 31.6%	execute_numeric_instruction 23.9%	flat_concat 5.8%
string_build_large1	execute_numeric_instruction 27.2%	execute_inner 25.1%	flat_concat 5.3%
string_build_large2	execute_inner 24.9%	execute_numeric_instruction 23.0%	flat_concat 6.3%
int_to_string	execute_numeric_instruction 21.5%	execute_inner 15.5%	from_validated_utf16 8.0%
float_to_string	mul 12.1%	shortest_sequence 9.4%	pow 7.7%
string_to_int	execute_inner 20.5%	execute_numeric_instruction 20.1%	to_numeric 7.0%
string_to_float	execute_inner 20.4%	execute_numeric_instruction 15.5%	to_numeric 10.6%
v8-richards	internal_get_or_missing 10.4%	execute_hot_instruction 7.6%	execute_inner 4.9%
v8-deltablue	internal_get_or_missing 10.0%	__memmove_avx512_unaligned_erms 5.9%	release_raw_no_drain 5.5%
v8-crypto	execute_inner 12.2%	execute_numeric_instruction 11.1%	to_numeric 9.0%
v8-raytrace	__memmove_avx512_unaligned_erms 12.5%	SipHash::write 8.8%	hash_one 4.8%
v8-earley-boyer	__memmove_avx512_unaligned_erms 8.9%	execute_inner 5.6%	release_raw_no_drain 4.8%
v8-regexp	Utf16Units::next 29.8%	execute_with_interrupt 6.4%	materialize_property_snapshot 2.6%
v8-splay	__memmove_avx512_unaligned_erms 16.8%	_int_malloc 4.8%	SipHash::write 4.6%
v8-navier-stokes	execute_inner 9.9%	execute_numeric_instruction 8.7%	internal_get_or_missing 4.2%

复现与原始证据

正式 fixed-work 重跑（路径替换为保留的已认证 ELF；外部负载按 manifest 校验字节）：

python3 scripts/benchmark/fixed.py \
  --manifest docs/reports/data-structure-fixed-final.json \
  --engine oxide=/absolute/ordinary-qjs \
  --engine quickjs=/absolute/quickjs-2026-06-04/qjs \
  --cpu 2 --repeat 5 --output target/post-pr19-fixed-repro

taskset -c 2 python3 scripts/benchmark/run.py --suite v8-v7 \
  --source /absolute/external-js-engine-benchmark \
  --engine oxide=/absolute/ordinary-qjs \
  --engine quickjs=/absolute/quickjs-2026-06-04/qjs \
  --repeat 1 --timeout 900 --output target/post-pr19-v8-repro
# 完整组合另运行：增加 --case all，timeout 改为 1800，并使用新 output 目录。

perf stat -e instructions:u,cycles:u,branches:u,branch-misses:u -- \
  taskset -c 2 /absolute/ordinary-qjs /absolute/fixed-case.js
perf record --per-thread -m 1024 -e cycles:u -c 1000003 \
  --call-graph dwarf,16384 -o /absolute/new-case.data -- \
  taskset -c 2 /absolute/ordinary-qjs /absolute/fixed-case.js

FP 诊断构建使用 git archive 1cc51bb 的干净副本，RUSTUP_TOOLCHAIN=1.94.1 CARGO_PROFILE_RELEASE_DEBUG=1 CARGO_PROFILE_RELEASE_STRIP=none RUSTFLAGS="-C force-frame-pointers=yes" cargo build --locked --release -p quickjs-oxide-cli --no-default-features --jobs 2；采样改为 --call-graph fp。需采用匹配 ELF/libc symbols，关闭 inline 展开；诊断配置及失败结果分开保留。

原始包 post-pr19-profile-2026-09-11-verified.tar.zst：339,978,516 bytes；SHA-256 f99681dd593eae52ab497d28bcbf5276ad0bf550bd2b89026d2bb8dd69fbb8bd。内含普通/FP/预算诊断 ELF 与 receipts、匹配 libc/debug、perf data、stat、stdout/stderr、逐轮样本、哈希 manifest 和采集脚本；4,246 个文件逐项解包核对大小与 SHA-256 通过。不含外部 benchmark JS 源码/生成负载，按固定 commit/manifest 重建。原始包目前保留在本机，未附公开下载；本评论已列出全部当前结果及失败状态。

后续实现应继续引用本评论的明确基线与验收口径；这份调查没有关闭本 issue，也不将候选优化标记为已完成。

[Eric-Song-Nop]

Tachyon 架构与 VM：我们应该吸收什么

本次将 Tachyon 加入 #16 的同机 benchmark，并将研究重点收敛为架构与 VM 设计。最值得吸收的是：显式执行状态、与运行时分离的不可变代码、以及有严格边界的热执行内核。 这比照着另一引擎的局部快路径逐项改写更有长期价值。

结论分三层：代码和小实验已经确认的能力；相对 QuickJS 在特定目标上的结构优势；仍需在 Oxide 上验证的演进方案。这里不分析 Tachyon 的性能短板，也不把微基准优势外推为整体优于 QuickJS。

1. 显式 Fiber / frame / continuation：最重要的架构参照

Tachyon 将 JS 调用状态放在 Fiber.frames: Vec<Frame> 和寄存器存储中。Frame 明确记录 code、function、pc、base、this、arguments、handler/completion 边界，编译期断言大小为 104 bytes。函数调用入帧、返回和需要执行 JS 的内置操作，通过解释器及 continuation 推进。
价值不是仅仅“减少一次函数调用”，而是让 JS 执行状态成为 VM 可管理的数据：暂停、恢复、预算调度、异常回退和 GC root 枚举可以围绕同一套状态组织。内置 String 转换、Array 回调等也能把跨 JS 调用的状态放进受 GC 管理的 continuation，避免状态只存在于宿主语言调用栈。
源码：crates/tachyon-vm/src/runtime/fiber.rs、crates/tachyon-vm/src/interpreter.rs、crates/tachyon-vm/src/string_concat.rs。
QuickJS 对照：普通 JS 调用使用 C 局部 JSStackFrame、alloca 的局部/操作数区，以及递归 JS_CallInternal；异步函数和 generator 另有持久状态。见 quickjs.c、quickjs.c。因此，在需要让任意深度的内部 JS 调用状态脱离宿主栈、统一调度的设计目标上，Tachyon 的组织方式更适合作为参照；这不意味着无限递归或没有资源限制。
对 Oxide：把宿主栈预算问题与普通 JS frame 的表示分开处理。先设计显式 frame/continuation 的所有权、return target、异常和 reentry 规则；不用先改 GC 或整套字节码。

2. 可恢复执行预算 + executor-neutral Future：已有可运行证据

Tachyon 区分 fuel 与 quantum；有界路径按字节码消耗预算，MAX/MAX 路径则选择编译期消除预算检查的实例。VmDriver 把 isolate 内的模块/Promise 工作推进映射为 Rust Future::poll，执行状态保留在 isolate，而非临时 Future 对象里。
本次编写并实际运行的架构探针：

• 创建一个 Promise job，在回调中执行 10,000 次求和循环；quantum 设为 8。
• 前 5 次 poll 后销毁宿主 Future，再为同一 Promise 创建新的 Future。
• 总计 10,003 次 poll 后得到正确结果 49,995,000。任务没有因 Future 重建丢失或从头执行。
  源码：crates/tachyon-vm/src/driver.rs、crates/tachyon-vm/src/driver.rs、crates/tachyon-vm/src/interpreter.rs。
  QuickJS 对照：JS_SetInterruptHandler 提供中断回调，JS_ExecutePendingJob 推进任务；中断返回失败进入异常，并非同一种 quantum 用尽后继续运行的 Future 协议。见 quickjs.c、quickjs.c、quickjs.c。
  对 Rust 服务内嵌脚本、多租户公平性、合作式取消，这种可恢复的调度契约比单纯设置 timeout 更有价值。实验覆盖 Promise job 的字节码执行；不能将它扩张为原生内置循环/GC 的硬实时保证，也不等同于现成的任意顶层 Script 公共 resume API。

3. 热内核与慢路径之间有可证明的边界，而非分散的 fast path

Tachyon 每个批次先取得已验证 bytecode cursor 与 register window，PC 留在局部变量中。热内核只执行不分配、不调用 JS、不改变寄存器 backing 的操作。遇到慢操作时先发布 PC，退出这段存储不变的执行区间，再执行完整语义逻辑并重新建立窗口。
核心实现：crates/tachyon-vm/src/interpreter.rs、crates/tachyon-vm/src/interpreter.rs、crates/tachyon-vm/src/runtime/code.rs。默认批次为 8：crates/tachyon-vm/src/tuning/dispatch.rs。
本次做了一个因果性更强的对照：只改 DEFAULT_DISPATCH_BATCH: 8 → 1，编译器、release 设置、脚本和 host 全相同；每项五轮交替运行。

负载	batch=8 ms	batch=1 ms	batch=1 / batch=8
empty_loop	113.30	203.79	1.80×
func_call	152.68	204.71	1.34×
int_arith	122.57	214.35	1.75×
float_arith	125.06	225.38	1.80×
string_length	160.76	194.83	1.21×

这说明批次内保存执行状态的收益在这些负载上确实存在；不是只根据两个不同引擎的跑分猜原因。它并不能单独解释全部跨引擎差距。
QuickJS 本身已经把 pc/sp 等放在 C 局部变量中，并支持 computed-goto 分派，见 quickjs.c。所以这里应学习的是 Rust 中“验证 → 稳定窗口 → 热内核 → 慢路径发布/重建”的结构，不能把“8 条一批”当成优于 QuickJS 的通用魔法。
对 Oxide：这是最适合先做受控原型的 VM 优化。保留现有语义入口，把 Number/Bool/局部值操作集中为一段没有可观察调用的执行区间，减少重复状态取用与回写。项目现有 unsafe_code = forbid 应保持；先探索安全 Rust 中的窗口和借用组织，不直接复制其 unchecked 访问。

4. 已验证的不可变代码：验证结果成为执行接口的一部分

Tachyon 的 Bytecode → VerifiedBytecode → CompiledModule 边界检查寄存器、常量、调用参数窗口、跳转到合法指令起点、函数布局及其他元数据；代码由不可变 Arc backing 持有。VM 热 decoder 明确依赖这些不变量，而非每条指令重新完成同一套结构验证。
源码：crates/tachyon-bytecode/src/lib.rs、crates/tachyon-bytecode/src/verify.rs。本次探针确认畸形 opcode 流在验证入口被拒绝。
QuickJS 官方文档明确要求不从不可信来源加载其序列化字节码。Tachyon 的结构验证边界因而是一个值得借鉴的设计点；单个拒绝探针不是完整安全审计，也不构成可以安全执行任意不可信序列化格式的承诺。QuickJS 文档
我们已经有相近基础：Oxide VerifiedFunction 和发布事务拥有验证后的草稿，防止验证后替换。下一步的价值是让执行层更充分使用已经建立的不变量，而不是重新造一遍校验器。

5. 代码与 Isolate 绑定分离：跨隔离堆共享编译产物

CompiledModule 保存 Arc 源码、常量描述、scope names 和函数；LoadedCode 则保存某个 isolate/realm 的 code identity、scope resolutions 与已物化 constant values。编译产物和运行时绑定是两个不同对象。
源码：crates/tachyon-bytecode/src/lib.rs、crates/tachyon-vm/src/runtime/code.rs。
本次实验确认：CompiledModule: Send + Sync 可通过编译；同一 module 在 Isolate A、B、A 执行计数脚本，依次返回 1、1、2。代码共享，两个全局环境保持独立。
QuickJS 的函数字节码持有 realm 指针，见 quickjs.c。跨独立 runtime 复用通常要处理序列化/重新加载与 runtime 绑定；同 runtime 的多个 context 可以共享对象，不应与跨隔离堆代码共享混为一谈。
这是服务器多 isolate、代码缓存和并行编译场景中，很可能比紧耦合运行时对象的方案更合适的结构。对 Oxide，可以评估将“可共享纯代码/常量描述”和“本地 atom、heap value、闭包环境、缓存”分层；先以重复加载同一程序的内存和初始化成本验收。

6. 64-bit 平台上的紧凑 Value：可直接确认的表示优势

在本机 x86-64 上实际编译检查：Tachyon Value = 8 bytes；QuickJS JSValue = 16 bytes。Tachyon 使用 NaN boxing 和 32-bit logical heap reference；QuickJS 此平台使用 payload + tag 的结构体。
源码：crates/tachyon-value/src/lib.rs、crates/tachyon-gc/src/layout.rs、quickjs.h。
这个优势指值数组、寄存器与 frame 中 Value 字段的密度：64-byte cache line 理论上可放 8 个而非 4 个 Value。整体内存并不因此自动减半；logical heap address、外部 backing、root 和 GC 元数据仍有自己的成本和约束。
对 Oxide：可以先量化 RawValue 在 operand/local/argument 存储中的尺寸和复制成本，评估“紧凑执行值 + 旁表/heap backing”作为独立架构方案。它与预算/热内核可以分别推进，不必打包成一次 GC 重写。

7. Root / NoGcScope / write barrier：把 GC 边界写进 API

Tachyon 的 Local 使用 generative lifetime 且不可跨线程传递；RunningScope 管理 root checkpoint；NoGcScope 暂时移除分配/收集 API，使借用 payload 的阶段和可能触发 GC 的阶段分开。write barrier、持久 root 和外部 backing 记账也有明确入口。
源码：crates/tachyon-gc/src/scope.rs、crates/tachyon-gc/src/scope.rs、crates/tachyon-gc/src/heap.rs。
最值得吸收的是“可分配/可观察”和“可借用/不可移动”的边界组织方式。它让热内核何时必须退出、临时 root 何时有效、跨调用状态由谁持有更容易表达与测试。QuickJS 的 RC+cycle-removal 有不同取舍；这里不能由 API 形式推出 tracing GC 必然更快。
对 Oxide：保留当前生命周期模型，先提炼内部 borrowed execution epoch 与拥有状态的 slow-path continuation，减少为跨层调用而反复 clone/retain/release 的需要。

8. 前端、运行时与宿主能力分层：为演进留出空间

Tachyon 把 Oxc 解析、owned HIR、register bytecode、VM 和 host providers 分开。register 指令显式编码来源/目的寄存器，函数布局在运行前确定；宿主提供时钟、熵、时区、Intl、任务驱动等能力，核心不隐式读取文件或依赖特定 executor。
源码：crates/tachyon-compiler/src/lib.rs、crates/tachyon-compiler/src/bytecode.rs、crates/tachyon-bytecode/src/encoding.rs、crates/tachyon-vm/src/host.rs。
这为后续局部数据流优化、独立编译、确定性宿主测试提供了清晰边界。它并不证明 register VM 必然优于 QuickJS 的紧凑栈字节码，也不代表已经具备成熟 SSA/JIT。
Oxide 已有 HostServices 和独立适配层；可借鉴的是把能力契约、暂停状态和编译结果进一步显式化，保留已有分层成果。

对我们下一阶段的建议

按架构收益与可分步验证的程度，建议做三个独立原型：

1. 显式执行状态与退出原因：梳理 frame、PC、operand/local、return target、异常和 reentry 状态，设计 Completed/Thrown/Yielded 的内部边界。用深调用、异常/重入与暂停恢复验证所有权；不先扩大宿主栈预算。
2. 验证后的原语执行批次：保留现有栈字节码，先为不分配、不调用 JS 的指令建立热内核；在完整语义边界发布状态并重新绑定。用 batch=1/4/8、硬件指令数和调用密集负载验证，而非只看单个空循环。
3. 共享纯代码 + 本地运行时绑定：抽出不含 runtime roots 的不可变代码，验证跨 isolate 重用、常量物化隔离和失效规则。若支持 Promise/模块 quantum 驱动，再测多任务公平性。
   紧凑 Value、分代 GC 和完整 register VM 作为随后单独评估的架构议题。静态 Atom 等局部优化仍可做，但不应成为这次 Tachyon 架构研究的主线。

用于支持架构判断的测量证据

已完成 58 个固定负载 × 3 引擎 × 5 轮 = 870 个输出通过的进程测量。另有匹配构建设置的 75 个样本、batch 8/1 的 50 个样本，以及聚焦 8 项的 24 次 profile / 72 次硬件计数。最终选用的 profile 无 lost samples。
三引擎固定基线是 Tachyon 2d148e462233c884d0547d4ec0ccc8ccaa183f17、Oxide PR19 引擎 1cc51bb5fcc5c36912d3197d877219ae513dc4b5 和 QuickJS 2026-06-04。QuickJS 源码与 release commit 3d5e064e9dd67c70f7962836505a7fa067bf0a4e 的 quickjs.c / quickjs.h blob 已核对相同。
同机 Ryzen 7 7840HS，CPU 2，五轮轮换顺序；未锁频，governor=powersave，存在桌面后台。计时包含整个进程；构建不与计时重叠。Tachyon 使用自建最小 host（上游 CLI 未实现），保留工作负载原体与 strict directive，单独加载 print/console.log，并提供 wall clock。正式矩阵统一限制 8 GiB 地址空间。Tachyon host 的 2 GiB managed heap、16,384 frames 等资源上限是显式比较配置，并非其仓库原有 benchmark_config 默认值。
Tachyon 普通构建：Rust 1.95.0 / thin LTO / 1 codegen unit / debug=2 / panic=abort。Oxide 普通历史基线为 Rust 1.94.1；为了检查构建混杂，将同一份 Oxide 源码改用前述 Tachyon 构建设置另测：

负载	Tachyon ms	普通 Oxide ms	匹配设置 Oxide ms	匹配 Oxide / Tachyon
empty_loop	112.51	501.06	495.27	4.40×
func_call	151.75	662.58	598.55	3.94×
int_arith	121.46	571.66	593.87	4.89×
string_length	160.56	597.45	532.08	3.31×
v8-crypto	1115.12	2043.17	1944.40	1.74×

匹配设置后差距仍存在，但这不是将每一项差距归因到某个架构决定的证明。真正隔离了单一设计参数的是上面的 batch 对照。
聚焦 profile 的两项纯计算负载中，empty_loop 约 96.8%、int_arith 约 96.3% 的样本落在已内联热内核的执行循环里；func_call 则可见执行循环、push_call_frame 和完整 dispatch 的分工。普通 ELF 用 cycles:u、周期 1,000,003、DWARF 16 KiB、per-thread 4 MiB buffer；只作叶子归因，不假定父调用栈可完整重建。
硬件指令数（三轮中位数，十亿条）如下；其中 opcode 数与硬件指令数不是同一指标：

负载	Tachyon instructions	Oxide instructions	QuickJS instructions
empty_loop	2.488	7.482	0.562
int_arith	2.641	7.386	0.565
func_call	3.048	9.289	0.537
string_length	3.538	8.653	0.313

未运行完整 Test262。定向探针发现了语义差异，保留在机器可读数据中；因此负载输出通过不能外推为全面语义等价。此处的建议基于设计机制、针对性行为实验和受控 batch 对照，不依赖“另一个引擎整体更好”的前提。

附录：全部 58 项固定负载时间（ms，中位数）

负载	Tachyon	Oxide	QuickJS
empty_loop	113.56	501.18	27.48
empty_down_loop	109.57	418.50	27.43
prop_read	414.99	654.01	24.62
prop_write	281.72	293.62	10.86
prop_update	332.96	389.46	10.95
prop_create	233.30	370.29	16.43
prop_clone	306.44	321.40	16.72
prop_delete	901.47	388.54	21.75
array_read	374.76	441.10	17.62
array_write	275.60	455.99	7.31
array_update	294.30	450.23	7.01
array_prop_create	433.62	576.52	7.91
array_slice	800.19	376.34	15.30
array_length_read	400.95	582.05	22.57
array_length_decr	3770.66	549.60	13.42
array_push	600.35	614.41	12.18
array_pop	1578.74	568.26	14.32
typed_array_read	256.10	301.26	13.65
typed_array_write	235.71	254.44	16.00
arguments_read	389.30	360.52	14.81
arguments_strict_read	382.37	331.63	10.27
global_read	358.55	351.13	16.87
global_write	501.04	367.00	22.68
local_destruct	236.35	135.29	7.93
global_func_call	446.48	716.73	33.07
func_call	152.55	675.95	31.03
func_closure_call	227.95	776.22	32.25
int_arith	120.45	575.14	35.60
float_arith	126.09	603.27	31.41
bigint64_arith	1625.79	460.62	47.95
map_set_string	786.32	37.50	5.55
map_set_int	395.14	48.84	5.19
map_delete	822.14	60.41	6.52
weak_map_set	290.33	334.05	22.09
array_for	273.99	394.03	19.70
array_for_in	1057.59	802.63	55.93
array_for_of	1538.83	555.84	17.86
math_min	545.95	753.05	35.13
regexp_ascii	1110.78	415.22	18.40
regexp_utf16	1119.18	420.49	18.54
regexp_replace	517.05	778.04	72.62
string_length	162.11	594.71	16.18
string_build1	1905.80	287.97	31.20
string_build3	1894.85	297.56	51.32
string_build_large1	31444.43	311.59	63.98
string_build_large2	31890.01	316.28	63.01
int_to_string	1002.19	279.93	44.00
float_to_string	1006.35	1569.00	245.46
string_to_int	224.62	163.77	30.20
string_to_float	226.00	136.27	46.36
v8-richards	56.73	75.25	5.95
v8-deltablue	91.37	134.37	8.63
v8-crypto	1105.17	2029.67	92.45
v8-raytrace	740.39	935.33	30.64
v8-earley-boyer	2754.94	2568.01	95.36
v8-regexp	2987.85	5511.35	318.33
v8-splay	4278.39	3127.16	401.28
v8-navier-stokes	1297.91	1699.86	59.64

复现与证据位置

• 新增接入与实验工具：scripts/benchmark/tachyon/README.md。普通 host、focused profiler、构建对照、batch ablation 和架构探针均有源码。
• 报告副本：docs/reports/tachyon-architecture.md；全部固定计时范围、计数器、profile、探针结果与构建哈希：docs/reports/tachyon-comparison.json。
• 原始 stdout/stderr、perf.data、计数器 CSV、固定 workload manifest、构建日志和诊断 patch 保留在 target/tachyon-comparison/，未声称公开上传。
• 广泛 profile 在研究范围收敛后已停止；未完成部分不计入结论。正式 profile 仅使用 architecture/ 的 8 项、每项 3 轮。没有继续排查 Tachyon 的慢项。
• batch 对照只在外部实验 checkout 临时更改一处常量；测量使用单独保存的 ELF。该源码与原普通 ELF 已恢复并核对哈希。未修改 Oxide 生产代码，也未发布或修改 Tachyon 上游。