微优化，现代浏览器是否已经进行了优化？

Question

最近我继承了一个库，其中有一个类上存在更新方法。以下是一个示例：

onPointerMove(pointer, x, y, isPressed){
    var floor = Math.floor;
    var cx = this.currentX;
    var cy = this.currentY;
    var tm = this.toolManager; 
}

这种代码大多只存在于性能关键的部分。项目的大部分内容都不是这样编写的。

1. Floor被使用了两次。将其缓存到本地变量中是否只会在每次运行时强制进行一些“临时”内存分配？这样做比查找函数更快吗？
2. 该函数体中多次引用this.currentX，但缓存它真的更快吗？我认为this.currentX不涉及任何查找问题，但也许我错了。既然这种情况发生在示例中剩余的代码中，所有这些属性都被缓存。

这些对于现代JavaScript引擎真的还有意义吗？我认为如果这样的优化更快...在V8内部会自动实现这样的优化。例如，如果在函数中调用Math.round 20次，则引擎会自动缓存它？

我也期望像在“for”之前缓存长度这样的操作是优化引擎解释代码时自动完成的另一个例子（仅当它确实有所区别时）。

我真正想知道的是...从今天起，我应该对我的代码进行微观优化（针对常绿浏览器）或者是否已经有新的技术取代了2010年（我读《高性能JavaScript》时）的这些优化技巧。

谢谢！

- Clark

---

除非你遇到了问题并使用了分析器找到了瓶颈/问题，否则不要进行优化（特别是：牺牲可读性/可维护性）。顺便说一句：如果你简单地使用分析器（或其他测量手段），你可以回答你帖子中的大多数问题，如果不是全部。只需构建一个测试用例并对其进行分析/测量即可。就这么简单。我会向你指出jsperf.com，但它目前已经关闭。 - RobIII

感谢指出 profiling RobIII！我已将它添加到我的待办事项列表中，以更好地理解这个过程。 - Clark

Answer 1

不要过早优化。除非一些分析表明代码中的这些内容实际上导致某种瓶颈或不成比例的资源使用，否则不要按照性能理论去优化它们。

至于实际性能：对象属性查找（例如Math.floor或this.currentX）是o（1）操作，因为它们实际上是哈希映射查找。将它们保存到变量中似乎更像是可读性的增强而不是其他任何东西。

- doldt