如何通过基准测试评估手写递归原型遍历与标准查找在时间上的耗时

真实评估需控制变量测底层耗时：现代引擎靠内联缓存优化属性访问，同一属性反复访问极快，而动态键、篡改原型或跨层首次访问易触发慢路径；基准测试应构造纯净原型链，用Benchmark.js压测并结合DevTools火焰图分析IC命中情况。

要真实评估手写递归原型遍历（如沿 __proto__ 或 Object.getPrototypeOf() 逐层向上查找属性）和标准查找（如 obj.prop、Object.hasOwn(obj, key) 或 key in obj）的时间开销，不能只比“写法看起来多几行”，而应控制变量、隔离引擎行为、测量可复现的底层耗时。

关键不是“递归几层”，而是“引擎是否优化了这次访问”

现代 JS 引擎（V8、SpiderMonkey）对属性访问做了大量运行时优化，尤其是内联缓存（IC）。同一属性反复访问会极快；动态键名、中途篡改原型、或跨多层首次访问，就容易触发慢路径。所以基准测试必须反映这些机制。

---

构造可控的原型链结构

目标：让属性只存在于第 N 层原型上，其余层都不含该键，强制引擎必须查到指定深度才能命中。

// 创建 0 层（自身有）const obj0 = { id: 42 };// 创建 3 层原型链：obj3 → obj2 → obj1 → obj0const obj1 = Object.setPrototypeOf({}, obj0);const obj2 = Object.setPrototypeOf({}, obj1);const obj3 = Object.setPrototypeOf({}, obj2); // id 只在 obj0 上

✅ 确保：

• 所有对象用 Object.setPrototypeOf 构造，避免 __proto__ 赋值引发引擎降级
• 键名统一（如 'id'），且不在中间层重复定义
• 避免使用 eval、with、delete 或修改 prototype 属性，防止 IC 失效

---

封装待测操作为纯函数

把逻辑收进无副作用、无外部依赖的函数里，便于 Benchmark.js 隔离运行：

// 标准访问（最快路径）const directAccess = (obj) => obj.id;// hasOwn 检测（安全、推荐）const hasOwnCheck = (obj, key) => Object.hasOwn(obj, key);// 手写递归原型遍历（模拟旧式 polyfill）const protoWalk = (obj, key) => {  let current = obj;  while (current != null) {    if (Object.prototype.hasOwnProperty.call(current, key)) {      return true;    }    current = Object.getPrototypeOf(current);  }  return false;};// in 操作符（走原型链，但不区分自有/继承）const inCheck = (obj, key) => key in obj;

⚠️ 注意：

• obj.key !== undefined 不是存在性检测，跳过它
• obj.hasOwnProperty(key) 不安全，必须用 Object.prototype.hasOwnProperty.call
• protoWalk 中每次 Object.getPrototypeOf 和 hasOwnProperty.call 都有开销，要计入

---

用 Benchmark.js 做函数级压测

安装：npm install benchmark
示例脚本：

const Benchmark = require('benchmark');const suite = new Benchmark.Suite();suite  .add('direct access', () => directAccess(obj3))  .add('Object.hasOwn', () => hasOwnCheck(obj3, 'id'))  .add('"in" operator', () => inCheck(obj3, 'id'))  .add('handwritten proto walk', () => protoWalk(obj3, 'id'))  .on('cycle', (e) => console.log(String(e.target)))  .on('complete', () => console.log('Fastest is ' + this.filter('fastest').map('name')))  .run({ async: false });

? 关键设置：

• 每个测试项用相同输入对象（如 obj3）
• 不在测试体里创建新对象或调用 console.log
• 运行前确保 JIT 已预热（Benchmark.js 默认处理）
• 关注 Hz（每秒执行次数）和误差 ±%；若 >1.5%，说明系统干扰大，需重跑

---

用 DevTools 定位为什么慢

基准告诉你“谁慢”，DevTools 告诉你“为什么慢”：

1. 在 Chrome 打开 Developer Tools → Performance
2. 点击录制，运行一段密集调用（如 for (let i = 0; i < 1e5; i++) protoWalk(obj3, 'id')）
3. 停止后看火焰图：
   • 是否出现大量 GetPropertyStub？→ 表明未命中 IC，走通用属性获取路径
   • 是否有 LoadIC_Miss？→ 引擎无法缓存该访问模式（比如键名非常规、原型被改写）
   • Object.getPrototypeOf 是否占高比例？→ 手写遍历的固有开销
   • 调用栈里有没有 FunctionCall 层层嵌套？→ 递归本身带来的帧管理成本

对比发现：directAccess 几乎全是 LoadIC_Hit；而 protoWalk 会触发多次 GetPropertyStub + GetPrototype，且无法内联。

---

避开典型误判陷阱

• ✅ 正确做法：属性只设在最深一层，其他层干净，才能测出“深度查找”真实代价
• ❌ 错误做法：用 {} 直接字面量测试 —— 引擎对字面量对象有特殊优化，结果失真
• ❌ 错误做法：混用 obj.__proto__.x —— V8 已弃用且禁用 IC，必然慢
• ❌ 错误做法：测试 obj.x = 123 赋值 —— 写入路径与读取路径优化策略不同，不可比

真正影响性能的，从来不是“递归了几层”，而是“引擎能否把它编译成一条内存偏移指令”。能，就快；不能，就退化成解释执行+多次原型跳转。

不复杂但容易忽略。