2

我在一个循环中运行函数 parLapply 并验证一个奇怪的行为。每次迭代的时间显着增加，这样的增加没有多大意义。

因此，我开始在周期内对函数进行计时，以查看哪个函数花费的时间最多，我发现 parLapply 花费了超过 95% 的时间。因此，我进入了 parLapply 函数并对其计时，以查看函数内部和外部之间的时间是否匹配。他们并没有很大的差距。这个余量随着时间的推移而增加，并且差异可以达到几秒钟，这对算法完成所需的时间产生了很大的影响。

while (condition) {
      start.time_1 <- Sys.time()

      predictions <- parLapply(cl, array, function(i){
        start.time_par <- Sys.time()

        #code

        end.time <- Sys.time()
        time.taken_par<- end.time - start.time_par
        print(time.taken_par)

        return(value)
      })

      end.time <- Sys.time()
      time.taken <- end.time - start.time_1
      print(time.taken)
}

我预计 time.taken 将类似于所有 time.taken_par 的总和。但事实并非如此。所有 time.taken_par 的总和通常为 0.026 秒，而 time.taken 开始时是该值的 4 倍，这很好，但随后会增加到更多（> 5 秒）。

谁能解释发生了什么和/或我认为应该发生的事情是否错误？是内存问题吗？

谢谢您的帮助！

编辑：

的输出parLapply如下。然而，在我的测试中，有 10 个列表，而不是本例中的 3 个。返回的每个单独列表的大小parLapply始终相同，在本例中为 25。

[1] 11
[[1]]
          1           2           3           4           5           6           7           8           9          10          11          12          13          14 
-0.01878590 -0.03462315 -0.03412670 -0.06016549 -0.02527741 -0.06271799 -0.05429947 -0.02521108 -0.04291305 -0.03145491 -0.08571382 -0.07025075 -0.07704650  0.25301839 
         15          16          17          18          19          20          21          22          23          24          25 
-0.02332236 -0.02521089 -0.01170326  0.41469539 -0.15855689 -0.02548952 -0.02545446 -0.10971302 -0.02521836 -0.09762386  0.02044592 

[[2]]
          1           2           3           4           5           6           7           8           9          10          11          12          13          14 
-0.01878590 -0.03462315 -0.03412670 -0.06016549 -0.02527741 -0.06271799 -0.05429947 -0.02521108 -0.04291305 -0.03145491 -0.08571382 -0.07025075 -0.07704650  0.25301839 
         15          16          17          18          19          20          21          22          23          24          25 
-0.02332236 -0.02521089 -0.01170326  0.41469539 -0.15855689 -0.02548952 -0.02545446 -0.10971302 -0.02521836 -0.09762386  0.02044592 

[[3]]
          1           2           3           4           5           6           7           8           9          10          11          12          13          14 
-0.01878590 -0.03462315 -0.03412670 -0.06016549 -0.02527741 -0.06271799 -0.05429947 -0.02521108 -0.04291305 -0.03145491 -0.08571382 -0.07025075 -0.07704650  0.25301839 
         15          16          17          18          19          20          21          22          23          24          25 
-0.02332236 -0.02521089 -0.01170326  0.41469539 -0.15855689 -0.02548952 -0.02545446 -0.10971302 -0.02521836 -0.09762386  0.02044592

编辑2：

好的，我发现了问题所在。我有一个数组，我使用vector("list",10000). 在循环的每次迭代中，我都会向这个数组添加一个列表列表。此列表列表的大小为 6656 字节。因此，在 10000 次迭代中，它甚至不等于 0.1Gb。然而，随着这个数组开始填满，并行化的性能开始下降。我不知道为什么会发生这种情况，因为我在具有 64Gb RAM 的机器上运行脚本。这是一个已知问题吗？

4

0 回答 0