真实评估需控制变量测底层耗时:现代引擎靠内联缓存优化属性访问,同一属性反复访问极快,而动态键、篡改原型或跨层首次访问易触发慢路径;基准测试应构造纯净原型链,用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 都有开销,要计入 安装: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 Hz(每秒执行次数)和误差 ±%;若 >1.5%,说明系统干扰大,需重跑 基准告诉你“谁慢”,DevTools 告诉你“为什么慢”:
for (let i = 0; i < 1e5; i++) protoWalk(obj3, 'id')) GetPropertyStub?→ 表明未命中 IC,走通用属性获取路径 LoadIC_Miss?→ 引擎无法缓存该访问模式(比如键名非常规、原型被改写) Object.getPrototypeOf 是否占高比例?→ 手写遍历的固有开销 FunctionCall 层层嵌套?→ 递归本身带来的帧管理成本 对比发现:directAccess 几乎全是 LoadIC_Hit;而 protoWalk 会触发多次 GetPropertyStub + GetPrototype,且无法内联。
{} 直接字面量测试 —— 引擎对字面量对象有特殊优化,结果失真 obj.__proto__.x —— V8 已弃用且禁用 IC,必然慢 obj.x = 123 赋值 —— 写入路径与读取路径优化策略不同,不可比 真正影响性能的,从来不是“递归了几层”,而是“引擎能否把它编译成一条内存偏移指令”。能,就快;不能,就退化成解释执行+多次原型跳转。
不复杂但容易忽略。