考虑未知 Javascript 引擎的代码，哪些因素对执行速度和内存节省影响最大？

Question

然后，我想，更完整的问题是，“当 Javascript 引擎已知时（基于每个流行的引擎），这些考虑因素如何受到影响。”

我觉得我需要询问“社区”的原因是，像 Strongloop 这样创建 Node.js 之类的东西的人，也编写了 util.inherits 之类的代码，一个函数在其中，而不是：TheConstructorFunction.prototype.constructor = TheConstructorFunction 他们创建了一个属性定义本身有 4 个属性被设置：

ctor.prototype = Object.create(superCtor.prototype, {
    constructor: {
        value: ctor,
        enumerable: false,
        writable: true,
        configurable: true
    }
});

这对我来说似乎效率低下，但是，与编写此类代码的作者相比，我在 3 年内一直在努力编写更好的 Javascript。有没有解释为什么这有效或无效？

一个答案说 util.inherits 并不是低效的，因为子类操作很少见。但是考虑到一些库处理在构建到测试结果观察之间发生的成百上千的子类操作，如果 Node.js 内部使用 util.inherits 那么这会影响其使用者的开发时间。我认为，在这个级别上，效率确实很重要，我希望 util.inherits 不会在内部使用。我什至不明白 util.inherits 的目的。为什么要拥有它？我认为它促进了复合效率低下。 require('util').inherits(C1,C2); 几乎是同义词，并且可能比 C1.prototype=Object.create(C2.prototype); C1.prototype.constructor=C1; 慢如果它只是为了吸引消费者，我对此很冷静。我担心这些专业人士是否在内部使用该功能，因为更大的库将取决于 Node.js 的效率。至于使.constructor 不可枚举......我认为它的“可枚举性”很重要的情况很少见，应该留给消费者，但如果内部操作取决于 util.inherits，这不是真的留给消费者。

Answer 1

JavaScript 引擎的作者最好回答这个问题。

这是一个称为性能调整的过程。

Here's Google's guide。 Here's Mozilla's guide.

让 Node.js 快速运行 javascript 是 Strongloop 业务的核心。他们采取了javascript优化seriously。

有一些陷阱，例如this。

不过，大多数情况下，不要阻塞事件循环 - 使用 Promise、异步操作、回调等。

用合理的实际测试用例对您的代码进行基准测试。确保检查覆盖范围。

一旦找到了寻找性能调优的主要原因，就必须开始深入挖掘。你必须分析你的代码。

Thorsten Lorenz 有一个老化但仍然主要相关的GitHub repository，其中包含许多有用的内部 V8 信息。

有很多开发者发帖blog articles、like this guy。你必须确保他们知道他们在说什么。他会的。

Bluebird 是一个众所周知的 Promises 实现，是正确优化的巅峰之作。他们有 an article 和 a guide 在他们注意到的事情上，这些事情只是扼杀优化的常见事情。

更新

您给出的 util.s 实现继承链的示例可能应该是一个单独的问题。我不确定他们是否在那里修补猴子，我必须查看其余的类和原型。

请参阅this MDN article，了解实现继承的已知方法的优缺点和变体，特别是Object.create 的使用，以及其他方法。

扩展内置原型_{（又名“猴子补丁”）} 的唯一充分理由是向后移植较新的 JavaScript 引擎的功能；例如 Array.forEach 等。

Here's 关于为什么会发生这种事情的一些推理。我answered a question 不久前关于将一个类注入到继承链的顶部，以便为所有子级添加扩展方法。这不是一个好主意。

原来，util.js 的 inherits 实现中的 Object.create 最初可能是一种优化尝试。根据early revisions，它使原型隐式不可变，理论上提高了方法解析性能。学究式地说，它从来都不是正确的，而且本质上一直是围绕 JavaScript 的原型继承功能进行的破解。新修订版将其替换为 Object.setPrototypeOf。

编辑：如果您对此投了反对票，我将不胜感激。

Answer 2

这对我来说似乎效率低下

没有。效率在这里并不重要。子类化是一种罕见的操作，即使代码比简单赋值慢（很可能没有太大区别），这也不会影响性能。

重要的是正确性，尤其是像utils.inherit 这样无处不在的库函数。那么他们为什么要使用属性属性呢？使 .constructor 不可枚举，就像它是标准的 .prototype 对象，这些对象是本机创建的，因此通常是预期的。

鉴于此处不需要考虑速度和内存，因此您似乎期望的优化不会在此处进行。