【问题标题】:Micro optimization, is it optimized anyway by modern browsers?微优化,是不是被现代浏览器优化了?
【发布时间】:2015-02-17 21:48:57
【问题描述】:

我最近继承了一个库,一个类上存在一个更新方法。这是一个例子。

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

这种代码大多只存在于性能关键的东西上。项目的其余大部分不是这样编写的。

  1. 地板使用了两次。肯定将其缓存在局部变量中只是在每次运行时强制进行一些“临时”内存分配?这比简单地查找函数要快多少?
  2. This.currentX 在函数体中被多次引用,但缓存它真的更快吗?我原以为this.currentX 不涉及查找问题,但也许我错了。由于示例中的其余代码都发生了这种情况,因此所有这些属性都被缓存。

这些在现代 JavaScript 引擎上真的更重要吗?我会假设这样的优化,如果它们更快的话......无论如何在V8中都会被视为优化的给定。例如,如果 Math.round 在一个函数中被调用了 20 次,那么引擎无论如何都会缓存它?

我还希望在您“为它”之前缓存一个长度之类的东西也是我认为优化引擎在解释代码时无论如何都会做的另一个例子(同样,只有当它甚至有所作为时)。

我真正想知道的是......从今天开始,我应该进行这些微优化(针对常青浏览器)并优化我的代码,还是从 2010 年(当我阅读性能JavaScript)

谢谢!

【问题讨论】:

  • 不要优化(尤其是:牺牲可读性/可维护性),除非您遇到问题并且使用分析器来查找瓶颈/问题。顺便说一句:如果您只是使用分析器(或其他测量方式),您可以回答帖子中的大部分问题(如果不是全部的话)。只需构建一个测试用例并对其进行分析/测量。就那么简单。我会指给你jsperf.com,但它目前已关闭。
  • 感谢您指出对 RobIII 的分析!我将它添加到我的待办事项列表中,以便更好地理解该过程。

标签: javascript optimization


【解决方案1】:

不要过早优化。除非某些分析表明代码中的这些东西实际上会导致某种瓶颈或不成比例的资源使用,否则不要费心按照性能理论来优化它们。

至于实际性能:对象属性查找(例如 Math.floor 或 this.currentX)是 o(1) 操作,因为它们实际上是 hashmap 查找。将它们保存到变量中看起来更像是增强了可读性。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2019-04-23
    • 1970-01-01
    • 1970-01-01
    • 2015-12-25
    • 2014-03-08
    • 2013-08-07
    • 2012-05-06
    • 1970-01-01
    相关资源
    最近更新 更多