Any way to inform ETA estimate with prior info?
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
Direzione di ricerca
Inizia tracciando l’API progressr::progressor(along = .x) e la chiamata immaginata pb(duration = t) nell’esempio minimo. Esamina come with_progress e handler_progress calcolano l’ETA, quindi definisci e testa il comportamento per la fornitura di durate di elaborazione precedenti, in modo che il lavoro saltato produca una stima più accurata.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
I'm working on a pipeline-prototyping package that uses progressr to track progress as many elements of a list are processed and where efficient re-processing is enabled by skipping over already processed elements. This results in a scenario where I gather the current ETA calculations of progressr become inaccurate as early elements that have already been successfully processed return from the processing function quickly while later elements can be expected to take much longer. I save history data associated with each element, including processing time duration, and I'm wondering if it'd be possible to provide that duration to progressr somehow to leave it with more accurate ETA estimates. A minimal example of my case is:
options(
progressr.handlers = progressr::handler_progress(
format = "[:bar] :spin :current/:total :percent in :elapsed ETA: :eta (:message)"
, clear = FALSE
)
)
options(progressr.clear=FALSE)
f = function(.x,pb){
x_hash = digest::digest(.x)
if(file.exists(x_hash)){
t = readRDS(x_hash)
}else{
t = runif(1,10,20)
Sys.sleep(t)
if(.x%%2){ # odd elements get saved, triggering skip next time they're processed
saveRDS(t,x_hash)
}
}
pb(duration = t) #imagined API for supplying the duration manually
}
#on first run, ETA is accurate
progressr::with_progress({
.x = 1:10
pb <- progressr::progressor(along = .x)
y = furrr::future_map(.x=.x,.f=f,pb=pb,.progress=F)
})
#on second run, some elements are skipped internally by f()
progressr::with_progress({
.x = 1:10
pb <- progressr::progressor(along = .x)
y = furrr::future_map(.x=.x,.f=f,pb=pb,.progress=F)
})
- Lingua principale
- R
- Stelle
- 299
- Fork
- 11
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Guida per i contributori
Apri la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di futureverse/progressr
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 63/100
futureverse/progressr#198 · 1 commento ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 45/100
futureverse/progressr#197 ·
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
futureverse/progressr#195 ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 28/100
futureverse/progressr#191 ·
-
question
Difficoltà 3/5 1-2 giorni Idoneità per principianti 35/100
futureverse/progressr#155 · 5 commenti ·
Tutte le issue di futureverse/progressr
Issue simili
-
Affects Web App documentation PRIORITY LOW
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 75/100
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 80/100
hubverse-org/hubCI#36 ·
-
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 85/100
-
Release 1.4.0 Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
pharmaverse/pharmaverseadam#170 ·