创建函数会消耗更多内存吗

发布于 2024-12-05 07:32:04 字数 480 浏览 4 评论 0原文

// Case A
function Constructor() {
  this.foo = function() {
    ...
  };
  ...
}

// vs 
// Case B
function Constructor() {
  ...
};

Constructor.prototype.foo = function() {
  ...
}

人们建议使用原型的主要原因之一是，在原型的情况下 .foo 创建一次，而在使用原型时 this.foo 创建多次其他方法。

然而，人们期望解释器可以优化这一点。因此，在情况 A 中，只有一个函数 foo 的副本。

当然，由于闭包，每个对象仍然拥有唯一的作用域上下文，但与每个对象的新函数相比，开销更少。

现代 JS 解释器是否优化了案例 A，使得函数 foo 只有一份副本？

原文

// Case A
function Constructor() {
  this.foo = function() {
    ...
  };
  ...
}

// vs 
// Case B
function Constructor() {
  ...
};

Constructor.prototype.foo = function() {
  ...
}

One of the main reasons people advise the use of prototypes is that .foo is created once in the case of the prototype where as this.foo is created multiple times when using the other approach.

However one would expect interpreters can optimize this. So that there is only one copy of the function foo in case A.

Of course you would still have a unique scope context for each object because of closures but that has less overhead then a new function for each object.

Do modern JS interpreters optimise Case A so there is only one copy of the function foo ?

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

吃→可爱长大的 2024-12-12 07:32:04

是的，创建函数会占用更多内存。

...并且，不，解释器不会将案例 A 优化为单个函数。

原因是 JS 作用域链要求函数的每个实例捕获其可用的变量它被创建的时间。也就是说，现代解释器是案例 A 比以前更好了，但很大程度上是因为闭包函数的性能几年来是一个已知问题以前。

Mozilla 表示，出于这个原因，要避免不必要的关闭，但关闭只是其中之一JS 开发人员工具包中最强大且最常用的工具之一。

更新：刚刚运行此测试，使用节点创建 1M 个构造函数“实例” .js（即 V8，Chrome 中的 JS 解释器）。使用 caseA = true 我得到了这样的内存使用情况：

{
    rss: 212291584,       //212 MB
    vsize: 3279040512,    //3279 MB
    heapTotal: 203424416, //203 MB
    heapUsed: 180715856   //180 MB
}

使用 caseA = false 我得到了这样的内存使用情况：

{
    rss: 73535488,       //73 MB
    vsize: 3149352960,   //3149 MB
    heapTotal: 74908960, //74 MB
    heapUsed: 56308008   //56 MB
}

因此，闭包函数肯定会消耗更多的内存，几乎增加了 3 倍。但从绝对意义上来说，我们只讨论每个实例约 140-150 字节的差异。（但是，这可能会增加，具体取决于创建函数时拥有的范围内变量的数量）。

Yes, creating functions uses more memory.

... and, no, interpreters don't optimize Case A down to a single function.

The reason is the JS scope chain requires each instance of a function to capture the variables available to it at the time it's created. That said, modern interpreters are better about Case A than they used to be, but largely because the performance of closure functions was a known issue a couple years ago.

Mozilla says to avoid unnecessary closures for this reason, but closures are one of the most powerful and often used tools in a JS developer's toolkit.

Update: Just ran this test that creates 1M 'instances' of Constructor, using node.js (which is V8, the JS interpreter in Chrome). With caseA = true I get this memory usage:

{
    rss: 212291584,       //212 MB
    vsize: 3279040512,    //3279 MB
    heapTotal: 203424416, //203 MB
    heapUsed: 180715856   //180 MB
}

And with caseA = false I get this memory usage:

{
    rss: 73535488,       //73 MB
    vsize: 3149352960,   //3149 MB
    heapTotal: 74908960, //74 MB
    heapUsed: 56308008   //56 MB
}

So the closure functions are definitely consuming significantly more memory, by almost 3X. But in the absolute sense, we're only talking about a difference of ~140-150 bytes per instance. (However that will likely increase depending on the number of in-scope variables you have when the function is created).

回复收藏 0 原文