gpt4 book ai didi

r - 当我使用 `furrr::future_map_int()` 时,为什么 `purrr::map_int()` 比 `dplyr::mutate()` 慢?

转载 作者:行者123 更新时间:2023-12-04 12:52:56 26 4
gpt4 key购买 nike

我有一个 tibble,其中包含一个带有向量的列表列。我想创建一个新列来说明每个向量的长度。由于这个数据集很大(300 万行),我想使用 furrr 来减少一些处理时间。包裹。然而,似乎purrrfurrr 快.怎么来的?
为了演示这个问题,我首先模拟了一些数据。不要费心去理解模拟部分中的代码,因为它与问题无关。

数据模拟功能

library(stringi)
library(rrapply)
library(tibble)

simulate_data <- function(nrows) {
split_func <- function(x, n) {
unname(split(x, rep_len(1:n, length(x))))
}

randomly_subset_vec <- function(x) {
sample(x, sample(length(x), 1))
}

tibble::tibble(
col_a = rrapply(object = split_func(
x = setNames(1:(nrows * 5),
stringi::stri_rand_strings(nrows * 5,
2)),
n = nrows
),
f = randomly_subset_vec),
col_b = runif(nrows)
)

}

模拟数据
set.seed(2021)

my_data <- simulate_data(3e6) # takes about 1 minute to run on my machine

my_data
## # A tibble: 3,000,000 x 2
## col_a col_b
## <list> <dbl>
## 1 <int [3]> 0.786
## 2 <int [5]> 0.0199
## 3 <int [2]> 0.468
## 4 <int [2]> 0.270
## 5 <int [3]> 0.709
## 6 <int [2]> 0.643
## 7 <int [2]> 0.0837
## 8 <int [4]> 0.159
## 9 <int [2]> 0.429
## 10 <int [2]> 0.919
## # ... with 2,999,990 more rows

实际问题

我想改变一个新列( length_col_a ),它将占 col_a 的长度.我要这样做两次。先用 purrr::map_int()然后用 furrr::future_map_int() .
library(dplyr, warn.conflicts = T)
library(purrr)
library(furrr)
library(tictoc)

# first with purrr:
##################
tic()
my_data %>%
mutate(length_col_a = map_int(.x = col_a, .f = ~length(.x)))

## # A tibble: 3,000,000 x 3
## col_a col_b length_col_a
## <list> <dbl> <int>
## 1 <int [3]> 0.786 3
## 2 <int [5]> 0.0199 5
## 3 <int [2]> 0.468 2
## 4 <int [2]> 0.270 2
## 5 <int [3]> 0.709 3
## 6 <int [2]> 0.643 2
## 7 <int [2]> 0.0837 2
## 8 <int [4]> 0.159 4
## 9 <int [2]> 0.429 2
## 10 <int [2]> 0.919 2
## # ... with 2,999,990 more rows
toc()
## 6.16 sec elapsed


# and now with furrr:
####################
future::plan(future::multisession, workers = 2)

tic()
my_data %>%
mutate(length_col_a = future_map_int(col_a, length))
## # A tibble: 3,000,000 x 3
## col_a col_b length_col_a
## <list> <dbl> <int>
## 1 <int [3]> 0.786 3
## 2 <int [5]> 0.0199 5
## 3 <int [2]> 0.468 2
## 4 <int [2]> 0.270 2
## 5 <int [3]> 0.709 3
## 6 <int [2]> 0.643 2
## 7 <int [2]> 0.0837 2
## 8 <int [4]> 0.159 4
## 9 <int [2]> 0.429 2
## 10 <int [2]> 0.919 2
## # ... with 2,999,990 more rows
toc()
## 10.95 sec elapsed

我知道 tictoc不是最准确的基准测试方法,但仍然 -- furrr应该更快( as the vignette suggests ),但事实并非如此。我确保数据没有分组,因为 author explained那个 furrr不适用于分组数据。那么对于 furrr还有什么其他解释呢?比 purrr 慢(或不是非常快) ?

编辑

我找到了 this issuefurrr的 github repo 讨论了几乎相同的问题。但是,情况不同。在github issue中,被映射的函数是一个用户定义的函数,需要附加额外的包。所以作者解释说每个 furrr worker 必须在进行计算之前附加所需的包。相比之下,我映射了 length()函数来自 base R ,所以实际上应该没有附加任何包的开销。
另外作者提出问题可能是因为 plan(multisession)没有在 RStudio 中工作。但是更新了 parallelly package to dev 版本解决了这个问题。
remotes::install_github("HenrikBengtsson/parallelly", ref="develop")
不幸的是,此更新对我的情况没有任何影响。

最佳答案

正如我在对原始帖子的评论中所争论的那样,我怀疑工作人员分发非常大的数据集会导致开销。
为了证实我的怀疑,我使用了 OP 使用的相同代码,并进行了一次修改:我添加了 0.000001 的延迟。结果是:purrr --> 192.45 secfurrr: 44.707 sec ( 8 workers )。 furrr所用的时间只是 purrr 拍摄的 1/4 ——离1/8还很远!
根据 OP 的要求,我的代码如下:

library(stringi)
library(rrapply)
library(tibble)

simulate_data <- function(nrows) {
split_func <- function(x, n) {
unname(split(x, rep_len(1:n, length(x))))
}

randomly_subset_vec <- function(x) {
sample(x, sample(length(x), 1))
}

tibble::tibble(
col_a = rrapply(object = split_func(
x = setNames(1:(nrows * 5),
stringi::stri_rand_strings(nrows * 5,
2)),
n = nrows
),
f = randomly_subset_vec),
col_b = runif(nrows)
)

}

set.seed(2021)

my_data <- simulate_data(3e6) # takes about 1 minute to run on my machine

my_data

library(dplyr, warn.conflicts = T)
library(purrr)
library(furrr)
library(tictoc)

# first with purrr:
##################

######## ----> DELAY <---- ########
f <- function(x) {Sys.sleep(0.000001); length(x)}

tic()
my_data %>%
mutate(length_col_a = map_int(.x = col_a, .f = ~ f(.x)))
toc()

plan(multisession, workers = 8)

tic()
my_data %>%
mutate(length_col_a = future_map_int(col_a, f))
toc()

关于r - 当我使用 `furrr::future_map_int()` 时,为什么 `purrr::map_int()` 比 `dplyr::mutate()` 慢?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/69808082/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com