我正在尝试实现一个需要非常快的功能,主要是因为它一次又一次地处理大量数据帧.
R总是让我迷惑为什么它有时候有点慢,以及为什么它在其他时候可笑得很慢.(不幸的是,从来没有快.)
无论如何,我总是假设,在可能的情况下,当以某种方式推入应用程序,sapply或lapply时,事情可以运行得更快,而不是放入循环中.我最近遇到了一个例子,让我觉得还有更多的内容,如果我理解它,可能会对未来的优化有很大的帮助.
以下是我在相对强大的Ubuntu Linux机器上运行的一些计算:
system.time(sapply(1:1e5, sum))
user system elapsed
35.130 0.000 35.128
system.time(sapply(1:1e5, cumsum))
user system elapsed
0.110 0.000 0.108
是的,你正在正确读取这些数字:cumsum,它创建一个累积和的数组,比仅提供简单的总和快几个数量级.(如果其他人可以在他们的机器上验证这些结果,那就太棒了!)
我不明白这是怎么可能的,除非实现有很大不同.假设它们确实有很大差异,我想知道以什么样的方式,以便在寻找速度时我可以寻找某些功能来避免.(对于核心功能,我不知道如何查看它们的来源.只是键入函数名称而没有任何括号的标准方法对核心函数不起作用.)
非常感谢!
Mar*_*gan 22
或多或少遵循使用operf的说明我用单行创建了一个文件sapply(1:1e5, sum)并运行
$ operf ~/bin/R-3-1-branch/bin/R -f sum.R
$ opreport -l ~/bin/R-3-1-branch/lib/libR.so |less
生产
CPU: Intel Sandy Bridge microarchitecture, speed 2.401e+06 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
samples % image name symbol name
835882 93.0929 libR.so RunGenCollect
27731 3.0884 libR.so SortNodes
9323 1.0383 libR.so AgeNodeAndChildren
2038 0.2270 libR.so CheckFinalizers
1593 0.1774 libR.so Rf_allocVector3
1222 0.1361 libR.so duplicate1
...
大部分时间都花在垃圾收集器上(RunGenCollect- 运行世代垃圾收集器).所以我跑了
$ R -d gdb R
(gdb) run
> sapply(1:1e5, sum)
^C
(gdb) break RunGenCollect
(gdb) continue
Continuing.
Breakpoint 1, RunGenCollect (size_needed=50000) at /home/mtmorgan/src/R-3-1-branch/src/main/memory.c:1504
1504 bad_sexp_type_seen = 0;
(gdb) where
哪个产生了
#0 RunGenCollect (size_needed=50000) at /home/mtmorgan/src/R-3-1-branch/src/main/memory.c:1504
#1 0x00007ffff789d354 in R_gc_internal (size_needed=50000) at /home/mtmorgan/src/R-3-1-branch/src/main/memory.c:2825
#2 0x00007ffff789e99b in Rf_allocVector3 (type=13, length=100000, allocator=0x0) at /home/mtmorgan/src/R-3-1-branch/src/main/memory.c:2563
#3 0x00007ffff788e1a5 in Rf_allocVector (type=13, length=100000) at /home/mtmorgan/src/R-3-1-branch/src/include/Rinlinedfuns.h:189
#4 0x00007ffff7831787 in duplicate1 (s=0x7ffff3b0b010, deep=TRUE) at /home/mtmorgan/src/R-3-1-branch/src/main/duplicate.c:335
#5 0x00007ffff783371a in duplicate_child (s=0x7ffff3b0b010, deep=TRUE) at /home/mtmorgan/src/R-3-1-branch/src/main/duplicate.c:199
#6 0x00007ffff783357a in duplicate_list (s=0x2c98b30, deep=TRUE) at /home/mtmorgan/src/R-3-1-branch/src/main/duplicate.c:261
#7 0x00007ffff7830fc2 in duplicate1 (s=0x2c98b30, deep=TRUE) at /home/mtmorgan/src/R-3-1-branch/src/main/duplicate.c:308
#8 0x00007ffff783371a in duplicate_child (s=0x2c98b30, deep=TRUE) at /home/mtmorgan/src/R-3-1-branch/src/main/duplicate.c:199
#9 0x00007ffff783357a in duplicate_list (s=0x2c98a88, deep=TRUE) at /home/mtmorgan/src/R-3-1-branch/src/main/duplicate.c:261
#10 0x00007ffff7830fc2 in duplicate1 (s=0x2c98a88, deep=TRUE) at /home/mtmorgan/src/R-3-1-branch/src/main/duplicate.c:308
#11 0x00007ffff7830c7f in Rf_duplicate (s=0x2c98a88) at /home/mtmorgan/src/R-3-1-branch/src/main/duplicate.c:132
#12 0x00007ffff79257f4 in do_summary (call=0x2c98a88, op=0x6259a0, args=0x303cf88, env=0x2c97f48) at /home/mtmorgan/src/R-3-1-branch/src/main/summary.c:462
...
这里的相关行是第462行
(gdb) up 12
#12 0x00007ffff79257f4 in do_summary (call=0x2c98a88, op=0x6259a0, args=0x303cf88, env=0x2c97f48) at /home/mtmorgan/src/R-3-1-branch/src/main/summary.c:462
462 PROTECT(call2 = duplicate(call));
(gdb) list
457 return ans;
458 }
459
460 /* match to foo(..., na.rm=FALSE) */
461 PROTECT(args = fixup_NaRm(args));
462 PROTECT(call2 = duplicate(call));
463 SETCDR(call2, args);
464
465 if (DispatchGroup("Summary", call2, op, args, env, &ans)) {
466 UNPROTECT(2);
电话正在重复
(gdb) call Rf_PrintValue(call)
FUN(1:100000[[5339L]], ...)
对于循环的每次迭代,触发垃圾收集.对于cumsum 不执行类似的代码.这种方式已经很长时间了,原因并非100%明显
$ svn annotate ~/src/R-3-1-branch/src/main/summary.c |less
...
42643 ripley /* match to foo(..., na.rm=FALSE) */
42643 ripley PROTECT(args = fixup_NaRm(args));
42643 ripley PROTECT(call2 = duplicate(call));
42643 ripley SETCDR(call2, args)
...
$ svn log -r42643
------------------------------------------------------------------------
r42643 | ripley | 2007-08-25 23:09:50 -0700 (Sat, 25 Aug 2007) | 1 line
make the rest of the group generics primitive
------------------------------------------------------------------------
在R-devel邮件列表中对此进行讨论会很有趣.它不是sum特别慢,而是对垃圾收集器的调用占主导地位的执行时间.
嗯,经过反思,结果证明了这一点
sapply(1:1e5, function(x) sum(x))
和...一样在球场上奔跑cumsum.我认为这是因为duplicate原始版本中的第462行正在制作1e5元素的副本,以准备选择要求的第i个元素.相反,在function(x) sum(x)向量中已经是子集,因此复制只是第i个元素.复制原始向量也解释了为什么1e5元素比1e4元素慢得多,为什么as.list(1:1e5)相对高性能(只有列表元素实际上是重复的,或者甚至不是那样).调用期间的重复sum与它属于(S3)Summary组泛型的事实有关,请参阅?"group generic".