【问题标题】:JavaScript Variable Access PerformanceJavaScript 变量访问性能
【发布时间】:2014-03-09 00:34:52
【问题描述】:

我目前正在使用 Node.js,并且已经构建了一个接受数据的套接字。我正在尝试以流式方式处理数据,这意味着我(几乎)在收到数据时处理数据。但是,我的代码中有一个相当大的瓶颈,这使我无法按我的意愿快速处理。

我已将问题提炼到下面的代码中,删除了无关信息,但它很好地捕捉到了我的问题:

require('net').createServer(function (socket) {
    var foo = [];

    socket.on('data', function (data) {
        foo.push(data); // Accessing 'foo' causes a bottle neck
    });

}).listen(8080);

更改data 事件中的代码可显着提高性能:

var tmpFoo = foo;
tmpFoo.push(data);
// Do work on tmpFoo

问题是,我最终需要访问全局 (?) 变量(为下一个data 事件保存信息);随之而来的是性能损失。我更愿意在收到数据时对其进行处理,但似乎无法保证它将是“完整”消息,因此我需要缓冲。

所以我的问题:

  • 是否有更好的方法来本地化变量并限制性能损失?
  • 有没有更好的方法以流方式处理数据?

【问题讨论】:

  • tmpFoo 和 foo 是一样的,所以如果你 push 到 tmpFoo,它也会在 foo 中...
  • 你怎么知道非本地引用会导致“瓶颈”?你是怎么测量的?我觉得这不太可能。它肯定比访问局部变量更昂贵,但时间量以几微秒为单位。
  • @Pointy 是的,我已经测量过了。虽然对于任何给定事件来说这只是最小的延迟,但我正在处理的速度/数据吞吐量会导致这种延迟迅速增加。
  • 这看起来有点难以置信——tmpFoo 只是一个指向foo 的指针,所以它仍然需要像foo 一样在执行tmpFoo.push 时取消引用。如果有的话,考虑到设置指针所需的额外指令,我认为使用 temp 变量会更慢。你如何衡量绩效?你确定更改那行代码吗?
  • 我也不认为这是个问题,所以在到达这条线之前我跑了几个兔子洞。我认为这是我在 foo 上进行的处理,所以我将其注释掉 - 相同的性能。我一注释掉对foo 的访问权限,它就立即加快了速度。本地化变量(即tmpFoo)保持了速度的提高,但在下一次迭代中丢失了数据。

标签: javascript node.js performance-testing


【解决方案1】:

不要使用这样的匿名函数:

 createServer(function (socket) {

单独定义函数并调用如下:

 var foo = [];

 function createMyServer(socket) {    
      socket.on('data', reveiveDataFromSocket);
 }

 function reveiveDataFromSocket(data) {
      foo.push(data);
 }

 require('net').createServer(createMyServer).listen(8080);

【讨论】:

  • 这不会产生可衡量的差异。
  • 这个问题已经问了快六年了。在现代 JavaScript 运行时中,差别很小。
  • 那个例子完全不一样。在 for 循环中定义一个函数会在每次迭代中创建一个新函数,而将一个函数传递给 createServer() 只会创建一个函数,无论该函数被调用多少次。我同意使用命名函数是一种更好的做法,但不是出于上述原因。
  • 无论它的年龄如何,在这种情况下这似乎并不相关。在 OP 的帖子中,每个函数只创建一次,这与您链接到的问答相反,其中函数是在循环内创建的。 @Pointy - 即使在今天的 Node 的情况下,我认为频繁创建函数的开销问题与编译器优化的潜在损失有关,其中大部分 v8 直到第二次运行函数时才适用,根据他们给出的工程演讲(可以在网上找到)——当然,影响会随着功能的复杂性而变化。
  • @Pointy - 确实可以共享它。我可能会为了好玩而快速地做一个基准测试。在微不足道的情况下(一个简单地添加两个数字的函数),函数创建与仅添加两个数字的影响是每百万次调用 0.037 秒(显然在我的机器上 - 0.002 与 0.039 是时间),所以我不要为此失眠。 :-)
猜你喜欢
  • 1970-01-01
  • 2015-07-20
  • 2012-11-28
  • 2021-11-13
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 2011-02-25
相关资源
最近更新 更多