furrr/purrr结合progressr进度条与计算进度不同步问题求助

核心问题分析 #

你遇到的进度条提前走完、和实际计算不同步的问题，本质是进度更新时机错误——大概率是在每行计算开始前就触发了进度更新，导致进度条先走完，而实际计算还在后台执行。正确的逻辑应该是完成一行计算后再更新进度。

完整实现代码 #

先加载依赖包：

library(tibble)
library(purrr)
library(progressr)

封装易用的行处理函数：

apply_rowwise <- function(data, .f, ...) {
  # 初始化进度条，总步数等于数据行数
  p <- progressor(nrow(data))
  
  # 遍历每行：先执行计算，再更新进度
  pmap(data, function(...) {
    # 执行用户传入的业务函数
    result <- .f(...)
    # 完成一行后触发进度更新
    p()
    result
  })
}

用户端使用示例 #

# 模拟一个耗时的业务函数
slow_calc <- function(x, y) {
  Sys.sleep(0.5) # 模拟计算耗时
  x * y
}

# 构造测试数据
test_tbl <- tibble(a = 1:10, b = 11:20)

# 调用时用with_progress激活进度条（progressr的要求）
with_progress({
  output <- apply_rowwise(test_tbl, slow_calc)
})

# 可选：把结果整理回tibble
output_tbl <- tibble(result = unlist(output))

并行处理适配（如果需要用future_pmap） #

如果要并行加速，只需替换遍历函数，保持进度更新逻辑不变：

library(future)
library(future.apply)

apply_rowwise_parallel <- function(data, .f, ...) {
  plan(multisession) # 设置并行策略，可根据机器调整
  p <- progressor(nrow(data))
  
  future_pmap(data, function(...) {
    result <- .f(...)
    p()
    result
  })
}

# 使用方式完全一致
with_progress({
  parallel_output <- apply_rowwise_parallel(test_tbl, slow_calc)
})

关键注意事项 #

1. 进度更新时机：必须在result <- .f(...)之后调用p()，确保进度条每一步都对应实际完成的计算。
2. with_progress的必要性：这是progressr的设计要求，用来激活进度条的渲染逻辑，用户端必须用它包裹函数调用。
3. 测试验证：测试时一定要用带耗时操作的函数（比如Sys.sleep），如果函数执行太快，进度条一闪而过是正常现象。

内容的提问来源于stack exchange，提问作者Fredrik Nylén