Open krivit opened 5 years ago
Benchmarks suggest that callr
is much slower:
f <- function() 2+2
microbenchmark(callr=r(f), mcp={j<-mcparallel(f()); mccollect(j)[[1]]})
Unit: milliseconds
expr min lq mean median uq max neval cld
callr 145.128327 154.612408 165.7934 162.1669 176.778607 220.87554 100 b
mcp 4.037625 5.281864 6.0387 5.7238 6.357726 10.86342 100 a
On, the other hand, not restarting the R session every time is not as bad:
library(callr)
library(microbenchmark)
library(parallel)
f <- function() 2+2
rs <- r_session$new()
microbenchmark(r=r(f), rs={rs$call(f); rs$poll_process(-1); rs$read()$result}, mcp={j<-mcparallel(f()); mccollect(j)[[1]]})
Unit: milliseconds
expr min lq mean median uq max neval cld
r 145.869876 153.497698 161.952199 158.633111 168.728134 222.200421 100 c
rs 17.170834 21.156948 24.776113 24.541950 28.002778 35.160594 100 b
mcp 1.980955 2.721543 2.998776 2.998492 3.285335 4.583885 100 a
forkTimeout()
usesparallel::mcparallel()
to impose a hard time limit on a function call. Unfortunately, this mechanism is not available on Windows. In all evidence, thecallr
package does not have this limitation. It may be worthwhile to switchforkTimeout()
to use it instead, assuming it does not impose too much of a speed penalty (and even if it does, use it on Windows only).Background
From statnet/ergm-private#230, certain inputs can reliably hang
ergm::is.inCH()
vialpSolve::lp()
, sending it into an infinite loop (or something indistinguishable from one):Commits c2210babc72761ac81398e4d2212a672bc036ff0 and statnet/ergm@c417215 mostly neutralise this problem on Unix-alikes
forkTimeout()
to terminate the call if it takes too long and rerun with invariantly perturbed input, which seems to always fix the problem.