Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Calling `.traceback()` within `future_Map` function call can slow things down terribly depending on data size

Aperta
  • Qualcosa non va?
#92 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Da chiarire
Stato di attività
Ferma
Stack tecnologico
r
Ambito
performance

Direzione di ricerca

Riproduci l’esempio R fornito che confronta Map() con future_Map(), includendo la temporizzazione di .traceback() e il print(x) opzionale. Esamina quindi l’implementazione di future_Map e il percorso indicato do.call(mapply, args=args) per determinare dove viene materializzato lo stack delle chiamate popolato. Il lavoro è completato quando la differenza di prestazioni e il comportamento di future_* interessato sono spiegati e coperti da un test di regressione.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

I recently implemented a new feature to my logger that requires the use of .traceback to fetch the function name and line number that generated that logger function call. A while later, I realised this was slowing things down drastically when run sequentially or in parallel with future_Map function. I am not sure if this has the same effect on other future_* functions (e.g., lapply).

Took me a while to figure out and come up with a small example, but here it is:

require(future)
require(future.apply)

myDF <- function(...) {
    t <- system.time(x <- .traceback(x=1))[["elapsed"]]
    cat("time: ", t, ", length: ", length(x), ", size_mb: ", object.size(x)/1024/1024, "\n", sep="")
    # print(x) # prints the entire call stack where the data is completely populated when called from future_Map
    base::data.frame(...)
}
 
ll <- replicate(3, sample(10, 1e6, TRUE), simplify=FALSE)
system.time(Map(function(x, y) myDF(x, y), ll, ll))
# time: 0, length: 6, size_mb: 0.002937317
# time: 0, length: 6, size_mb: 0.002937317
# time: 0, length: 6, size_mb: 0.002937317
#    user  system elapsed
#    0.15    0.00    0.16

system.time(future_Map(function(x, y) myDF(x, y), ll, ll))
# time: 4.24, length: 27, size_mb: 53.27061
# time: 4.15, length: 27, size_mb: 53.27061
# time: 4.18, length: 27, size_mb: 53.27061
#    user  system elapsed
#   13.01    0.03   13.05

If you uncomment the print(x) statement and run them, you'll see the difference in the way the call is populated. This is probably because of the way you use do.call() in generating the mapply function call: do.call(mapply, args=args). Here args, every element of args gets evaluated and are therefore not just calls/expressions, but materialised objects, I suspect.

Lingua principale
R
Stelle
218
Fork
20
Merge medio
2g 9h
PR unite (30g)
1

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di futureverse/future.apply

Tutte le issue di futureverse/future.apply

Issue simili

Altre issue su R

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.