Any way to inform ETA estimate with prior info?
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 25/100
Línea de trabajo
Comienza rastreando la API progressr::progressor(along = .x) y la llamada imaginada pb(duration = t) en el ejemplo mínimo. Revisa cómo with_progress y handler_progress calculan la ETA; después, define y prueba el comportamiento al proporcionar duraciones de procesamiento previas para que el trabajo omitido produzca una estimación más precisa.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
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)
})
- Lenguaje dominante
- R
- Estrellas
- 299
- Forks
- 11
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de futureverse/progressr
-
progressr fails to load on R<4Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 63/100
futureverse/progressr#198 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
futureverse/progressr#197 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
futureverse/progressr#195 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 28/100
futureverse/progressr#191 ·
-
question
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
futureverse/progressr#155 · 5 comentarios ·
Todos los issues de futureverse/progressr
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 90/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
Open-Systems-Pharmacology/OSPSuite.ParameterIdentification#330 ·
-
core
Dificultad 1/5 Menos de una hora Aptitud para principiantes 86/100
insightsengineering/teal#1747 ·
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
JamesHWade/deputy#236 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 3 días