通过原型定义方法vs在构造函数中使用它 – 真的是性能差异?

在JavaScript中,我们有两种方法来创build一个“类”并赋予其公共职能。

方法1:

function MyClass() { var privateInstanceVariable = 'foo'; this.myFunc = function() { alert(privateInstanceVariable ); } } 

方法2:

 function MyClass() { } MyClass.prototype.myFunc = function() { alert("I can't use private instance variables. :("); } 

我读过无数次的人说 ,使用方法2更有效,因为所有的实例共享相同的函数副本,而不是每个都获得自己的副本。 通过原型定义函数有一个巨大的缺点 – 它使得不可能有私有的实例variables。

尽pipe从理论上讲,使用方法1给每个对象的实例提供了自己的函数副本(因此使用更多的内存,更不用说分配所需的时间了) – 实际上实际发生了什么? 看起来像一个优化的Web浏览器可以很容易地认识到这个非常普遍的模式,并且实际上所有的对象实例引用通过这些“构造函数”定义的相同的函数副本。 然后,如果稍后显式更改,则只能为该实例提供自己的副本。

任何见解 – 或者甚至更好的现实世界的经验 – 关于两者之间的performance差异将是非常有用的。

http://jsperf.com/prototype-vs-this

通过原型声明你的方法更快,但不pipe这是否相关是值得商榷的。

例如,如果您的应用程序中存在性能瓶颈,则不太可能是这样,除非您恰好在某些任意animation的每一步中实例化了10000多个对象。

如果性能是一个严重的问题,你想微观优化,那么我会build议通过原型声明。 否则,只要使用对你最有意义的模式。

我将补充一点,在JavaScript中,有一个前缀属性的约定,意图被视为私有的下划线(例如_process() )。 大多数开发商会理解和避免这些属性,除非他们愿意放弃社会契约,但在这种情况下,你可能不会迎合他们。 我的意思是说:你可能不需要真正的私有variables

在新版本的Chrome中,this.method比prototype.method快大约20%,但创build新对象的速度仍然较慢。

如果您可以重复使用该对象,而不是始终创build一个新对象,则可以比创build新对象快50%至90%。 加上没有垃圾收集的好处,这是巨大的:

http://jsperf.com/prototype-vs-this/59

只有在创build大量实例时才有所作为。 否则,调用成员函数的性能在两种情况下都是完全相同的。

我在jsperf上创build了一个testing用例来演示这个:

http://jsperf.com/prototype-vs-this/10

你可能没有考虑到这一点,但直接将方法直接放在对象上的方式实际上更好:

  1. 方法调用的速度要稍微快一些 ( jsperf ),因为原型链不需要咨询来解决方法。

但是,速度差异几乎可以忽略不计。 最重要的是,在原型上添加一个方法更有两个更有效的方法:

  1. 更快创build实例 ( jsperf )
  2. 使用较less的内存

就像詹姆斯说的那样,如果你正在实例化一个类的数千个实例,那么这种差异就很重要。

也就是说,我当然可以想象一个JavaScript引擎,它可以识别你连接到每个对象的函数不会在实例间发生变化,因此只会保留内存中的一个副本,所有实例方法都指向共享函数。 事实上,Firefox似乎正在做一些特殊的优化,但Chrome并不是。


在旁边:

你是对的,不可能从原型的内部方法访问私有的实例variables。 所以我想你必须问自己的问题是,你是否重视能够使用inheritance和原型来使实例variables真正的私有? 我个人认为把variables变成真正的私有并不重要,只要使用下划线前缀(例如“this._myVar”)来表示尽pipevariables是公开的,但它应该被认为是私有的。 也就是说,在ES6中,显然有一个两全其美的方法!

简而言之,使用方法2创build所有实例将共享的属性/方法。 这些将是“全球化”的,任何改变都将反映在所有情况下。 使用方法1创build实例特定的属性/方法。

我希望我有一个更好的参考,但现在看看这个 。 你可以看到我如何在同一个项目中使用两种方法来达到不同的目的。

希望这可以帮助。 🙂

这个答案应该被认为是填补了缺点的其余答案的扩展。 个人经验和基准都被纳入。

就我的经验而言,我使用构造函数来虔诚地构build我的对象,无论方法是否私有。 主要的原因是,当我开始时,这是对我来说最简单的直接方法,所以这不是一个特殊的偏好。 这可能是一样简单,我喜欢可见的封装和原型有点无形。 我的私有方法也将作为范围内的variables。 尽pipe这是我的习惯,并且保持了很好的自我包容,但并不总是最好的习惯,而且我有时也会碰壁。 除了根据configuration对象和代码布局进行高度dynamic自组装的怪异场景,在我看来,这往往是更弱的方法,特别是如果性能是一个问题。 知道内部是私人的是有用的,但你可以通过其他方式来实现这一点,正确的纪律。 除非性能是一个严肃的考虑,否则使用任何最好的工具,否则为手头的任务。

  1. 使用原型inheritance和约定将项目标记为私有会使得debugging变得更简单,因为您可以轻松地从控制台或debugging器遍历对象graphics。 另一方面,这样的惯例会使混淆变得更加困难,并且使其他人更容易将自己的脚本粘贴到您的网站上。 这是私人范围方法获得普及的原因之一。 这不是真正的安全,而是增加了阻力。 不幸的是,很多人仍然认为这是编写安全JavaScript的真正方法。 由于debugging器变得非常好,代码混淆取代了它的地位。 如果您正在寻找客户端上安全漏洞太多的地方,那么这是您可能需要注意的一种devise模式。
  2. 一个约定允许你有一点小题大做的保护属性。 这可能是一个祝福和诅咒。 它确实缓解了一些inheritance问题,因为它的限制性较小。 在考虑其他地方可能会被访问​​的情况下,您仍然有碰撞或增加认知负担的风险。 自我组装的东西让你做一些奇怪的事情,你可以解决一些inheritance问题,但它们可以是非常规的。 我的模块往往有一个丰富的内部结构,其中的东西不被拉出来,直到function需要在别处(共享)或暴露,除非需要外部。 构造函数模式往往会导致创build自包含的复杂模块,而不仅仅是零碎的对象。 如果你想,那就没事了。 否则,如果你想要一个更传统的面向对象的结构和布局,那么我可能会build议按照惯例调整访问。 在我的使用场景中,复杂的OOP并不经常被certificate是正确的,模块可以做到这一点。
  3. 这里的所有testing都是最小的。 在现实世界的使用情况下,模块可能会更复杂,使得命中率远远超过这里所指出的testing。 有一个私有variables与多个方法的工作是相当普遍的,每个这些方法将增加更多的初始化开销,你不会得到原型inheritance。 在大多数情况下是没有关系的,因为只有less数这样的对象的实例浮起来,尽pipe累积起来可能会累加起来。
  4. 有一个假设,原型方法由于原型查找而调用较慢。 这不是一个不公平的假设,我自己也一样,直到我testing它。 实际上这很复杂,有些testing表明这个方面是微不足道的。 在之间, prototype.m = fthis.m = fthis.m = function...后者performance明显好于前两个执行大约相同。 如果单纯的原型查找是一个重大的问题,那么最后两个函数会显着地执行第一个function。 相反,其他奇怪的事情至less在金丝雀所关心的地方正在发生。 可能的function是根据它们的成员进行优化的。 多种性能考虑因素发挥作用。 参数访问和variables访问也有差异。
  5. 内存容量。 这里没有很好的讨论。 你可以做出一个假设,这很可能是真实的,原型inheritance通常会更有效率的记忆,根据我的testing,通常是这样。 当你在你的构造函数中构build你的对象时,你可以假设每个对象可能都有自己的每个函数的实例,而不是共享的,一个更大的属性映射用于它自己的个人属性,并且可能还有一些开销来保持构造函数的作用域。 在私人范围内运作的function对存储器的要求极高且不成比例。 我发现在很多情况下,内存中的比例差异比CPU周期中的比例差异要大得多。
  6. 内存图。 您也可以阻塞引擎,使GC更昂贵。 分析器倾向于显示这些天在GC中花费的时间。 分配和解放问题不仅是一个问题。 你也会创build一个更大的对象图来遍历,所以GC消耗更多的周期。 如果您创build了一百万个对象,然后几乎不触及它们,则取决于引擎,可能会产生比预期更多的环境性能影响。 我已经certificate,这至less可以使物体在处理物体时运行更长的时间。 这往往与使用的内存和GC所花的时间有关。 但是,无论内存如何,时间都是一样的。 这表明graphics化妆(间接,项目数量等)有更多的影响。 这并不总是容易预测的。
  7. 广泛使用链式原型的人不多,我自己也不得不承认。 原型链在理论上可能是昂贵的。 有人会但我没有测量成本。 如果你在构造函数中完全build立你的对象,然后有一个inheritance链,因为每个构造函数调用一个父构造函数,理论上来说方法访问应该快得多。 另一方面,如果重要的话,你可以完成相同的事情(比如将原型平铺在祖先链上),如果你真的需要的话,你不介意像hasOwnProperty,也许是instanceof等。 在这两种情况下,事情开始变得复杂一旦你在这条道路上performance黑客。 你可能最终会做你不应该做的事情。
  8. 许多人不直接使用你提出的方法。 相反,他们使用匿名对象做自己的事情,允许方法共享任何方式(例如mixin)。 还有一些框架可以实现自己的组织模块和对象的策略。 这些都是基于惯例的习惯方法。 对于大多数人和你来说,你的第一个挑战应该是组织而不是performance。 这通常是很复杂的,因为Javascript提供了许多方法来实现语言或者具有更明确的OOP /名称空间/模块支持的平台。 谈到表演,我会说,而不是首要的主要陷阱。
  9. 有一个新的符号types应该为私有variables和方法工作。 有很多方法可以使用它,并引发了一系列与性能和访问相关的问题。 在我的testing中,符号的performance与其他一切相比都不是很好,但我从来没有彻底地testing过。

免责声明:

  1. 关于性能的讨论很多,在使用场景和引擎发生变化时,并不总是有永久正确的答案。 始终configuration文件,但也总是以多种方式测量,因为configuration文件不总是准确或可靠的。 除非确实存在明显的问题,否则应避免进行大量的优化。
  2. 在自动化testing中包含对敏感区域的性能检查,并在浏览器更新时运行可能更好。
  3. 请记住,有时电池寿命以及可感知的性能。 在运行优化编译器之后,最慢的解决scheme可能会变得更快(IE,编译器可能更好地了解何时访问受限的作用域variables,而不是按照约定标记为私有的属性)。 考虑像node.js这样的后端。 这可能需要比您经常在浏览器上find的更好的延迟和吞吐量。 大多数人不需要担心这些东西,像registry格的validation,但这种事情可能重要的不同场景的数量正在增加。
  4. 你必须小心内存分配跟踪工具来坚持结果。 在某些情况下,我没有返回并坚持数据完全优化,或者实例化/未引用之间的采样率是不够的,让我挠头如何一个数组初始化和填充到一百万注册为3.4KiB在configuration文件中。
  5. 在现实世界中,大多数情况下,真正优化应用程序的唯一方法是首先编写它,以便测量它。 有几十到几百个因素可以发挥作用,如果不是在任何情况下数千。 发动机也会做一些事情,导致不对称或非线性的性能特征。 如果你在一个构造函数中定义函数,它们可能是箭头函数或传统函数,在某些情况下每个函数的行为都不一样,我不知道其他的函数types。 对于应该是等价的原型构造函数,类的performance也不一样。 你也需要非常小心基准testing。 原型类可以以各种方式进行延迟初始化,特别是如果你的原型也是你的原型(build议,不要)。 这意味着您可以低估初始化成本并夸大访问/资产突变成本。 我也看到了渐进式优化的迹象。 在这些情况下,我已经填充了一个大对象的实例相同的实例,随着实例的数量增加,对象似乎在内存中进行了增量优化,直到剩余部分相同。 这些优化也可能会显着影响CPU的性能。 这些事情不仅严重依赖于您编写的代码,而且还会在运行时发生诸如对象数量,对象之间的差异等。