为何在purrr::pmap()中调用外部函数比直接执行代码效率更低？

核心原因：函数调用的额外开销 #

R的函数调用并非无成本——每次调用函数时，都会触发一系列后台操作：参数匹配、查找函数所在环境、创建/销毁函数栈帧、处理返回值等。当你在pmap里直接写逻辑（比如\(x,y) x+y），这些代码是内联执行的，没有额外的函数调用开销；但如果把逻辑封装成外部函数f，再在匿名函数里调用f(x,y)，相当于每一行数据都多触发了一次完整的函数调用流程。在你的极简示例里，数据量是1e6行、循环50次，总调用次数达到5e7次，这个开销被无限放大，最终导致2秒vs35秒的巨大差异。

补充测试中三种写法的速度差异解析 #

针对你补充的列表列测试，三种写法的速度排序t1 > t2 > t3，具体原因如下：

• t1最快：匿名函数里直接执行逻辑，alpha和beta直接从外部环境读取，没有任何额外的函数调用或参数拼接操作，是最直接的执行路径。
• t2比t1慢：当你用pmap(dfr, func, alpha=alpha, beta=beta)时，purrr需要做额外的参数拼接工作——它要把数据框的列参数（a,b,c,d,e）和你传入的额外参数（alpha,beta）整合成一个完整的参数列表，再传递给func。这个参数组合的过程会产生额外的调度开销，所以比t1慢。
• t3最慢：这种写法是双重函数调用——每次迭代先执行pmap的匿名函数，再在里面调用func，两层函数的调用开销叠加，自然是最慢的。

优化小技巧（可选） #

如果需要复用复杂的函数逻辑又不想损失太多性能，可以尝试：

• 用purrr::partial预先绑定额外参数（比如func_partial <- partial(func, alpha=alpha, beta=beta)），再传入pmap，能减少部分参数拼接的开销。
• 对于极端性能要求的场景，可以考虑把核心逻辑用Rcpp重写，彻底绕过R的函数调用开销。

内容的提问来源于stack exchange，提问作者arb