¿Por qué las barras de progreso son tan inexactas? [cerrado]

Las computadoras y los lenguajes de programación tienden a ser deterministas y predecibles. Sin embargo, las barras de progreso parecen lo contrario, especialmente si la operación es compleja. Incluso para productos profesionales de clase mundial, algunas barras de progreso hacen poco para reflejar el progreso real de una operación. Los he visto pasar del 10% al 90% de un salto después de no hacer nada durante 4 horas. Incluso he visto algunos pasos hacia atrás, lo que sugiere que se ha descubierto un procesamiento inesperado adicional.

Concedido que puede haber operaciones de base de datos, procesamiento de red y operaciones paralelas, pero parece que esto podría cuantificarse de alguna manera y un porcentaje estimado. Después de todo, debe haber una cantidad finita de instrucciones ejecutadas para completar una operación. ¿Es esto simplemente una mala codificación, o hay alguna razón fundamental que represente que el progreso es difícil?

Para agregar a las respuestas más generales hasta ahora, puedo dar algunos ejemplos de mi campo donde las barras de progreso no funcionan y por qué;

Programas de diseño asistidos por computadora: los programas que realizan análisis térmicos o mecánica de fluidos pueden ser generalmente terribles con las barras de progreso. Saltan hacia adelante, hacia atrás, dan pasos inconsistentes y casi no sirve de nada mirarlos. Esto se debe a la naturaleza iterativa de este tipo de simulaciones y a la necesidad de encontrar convergencia. Esto se ve mejor no mediante una barra de progreso sino mediante un diagrama de iteración v convergencia.

Simulaciones complejas: escribí un programa que simula un entorno complejo con muchos factores cruzados. Era para una línea de tiempo fija, por lo que esta barra de progreso podría ser el momento adecuado. En mi caso, la simulación es demasiado larga con cada nuevo paso de tiempo, lo que significa que la barra de progreso se vuelve más y más lenta, no es genial. Encontré otra métrica para el tiempo que demora la simulación promedio en función del número de elementos en la simulación que estaba más cerca de la precisión, pero no es ideal, ya que a veces la barra de proceso nunca se llenó (la simulación se detuvo antes) o llegó al 100% antes (ejecución de la simulación) más de lo esperado).

En cualquier caso, una barra completa de progreso puro sería imposible calcular el máximo de antemano (caso 1) o ninguno lineal y, por lo tanto, no es muy útil (caso 2)

Ambos. A veces es difícil estimar cuánto tiempo llevará una operación, porque no sabes con anticipación cuánto trabajo hay que hacer. A veces sus estimaciones simplistas e inexactas.

Ejemplo: estoy descargando cuatro archivos simultáneamente. Alguien sabe qué tan grande es cada archivo, cuánto se ha descargado y cuántos megabytes por segundo se descargaron para cada archivo. Parece fácil predecir cuánto tiempo llevará. Sin embargo, sé que después de descargar un archivo, los otros se descargarán más rápido. Aún más después de descargar 3 archivos; la última se descargará cuatro veces más rápido. Nunca he visto ninguna barra de progreso teniendo esto en cuenta.

Ejemplo: está copiando una carpeta grande. La barra de progreso supone que copia X megabytes por segundo, sabe cuántos megabytes hay y su velocidad promedio hasta el momento. El problema es que "megabytes por segundo" es muy impreciso: en la práctica, toma x milisegundos por archivo, más y milisegundos por megabyte. Por lo tanto, muchos archivos pequeños tardan mucho más de lo que anticipa la barra de progreso.

El problema es que a los desarrolladores de software les puede importar, pero sus gerentes no lo hacen mientras su computadora no se bloquee.

Creo que la respuesta general es que a menudo es demasiado complejo (o imposible) calcular la cantidad de tiempo que llevará.

A veces, solo se trata de reducir el tiempo de computación para estimar mejor la cantidad de trabajo requerido (por ejemplo, tomar un mejor análisis de los archivos que se copiarán o aplicar un cálculo más complejo para estimar mejor la cantidad de pasos necesarios para completar una simulación).

Otras veces es bastante indeterminado. Cuando su sistema está instalando un nuevo programa, a menudo tiene muchas dependencias para verificar que estén instaladas. Y, en general, no tiene una idea de cuánto tiempo tomará cada uno y qué dependencias pueden necesitar. Es posible que ya tenga todas las dependencias instaladas y que pueda demorar 30 segundos, o que le falten docenas y demore horas. Es difícil dar un estadio justo sobre eso, especialmente cuando cada situación será única.

Además, otros drenajes en el sistema pueden cambiar con el tiempo (debido a lo que hace el usuario ... o a los procesos en segundo plano / programados).

A veces, la estimación podría mejorarse si el programador les dedicara un poco más de trabajo. Pero entonces es otra realidad que probablemente esta no sea la principal preocupación de la mayoría de los desarrolladores, en comparación con el avance de las tareas productivas reales que la aplicación puede realizar.

Al final, en este momento, creo que a menudo es solo una estimación lineal, un vistazo a cuántas de las tareas básicas requeridas ha completado el programa. Entonces, de hecho, tiende a ser una estimación muy aproximada, y generalmente debería considerarlo como tal al entrar.

---

Una buena analogía podría ser cuando estás leyendo un libro.
Y decide que le gustaría tener una idea de cuánto tiempo llevará terminar el libro ...
Puede verificar el recuento de páginas y obtener una estimación rápida basada en el ritmo hasta el momento.
Podría ser una mala estimación si recién comenzaste a leer, porque tu velocidad podría no ser típica todavía. Pero a menudo sería una suposición bastante aproximada.
O también puede hojear el libro, tener una idea aproximada de cuántas imágenes hay y el espaciado del texto. Y luego ten una mejor idea de lo que enfrentas.
Pero aún puede ser una estimación pobre si, por ejemplo, la legibilidad del texto disminuye, quizás pasando de una prosa simple a una compleja. O la estimación puede terminar muy mal porque no pudo anticipar otra tarea que distraiga su atención.
Podría obtener una gran estimación aplicando una gran cantidad de tiempo para analizar cuidadosamente lo que queda en el libro página por página, y también podría mejorarlo al revisar su calendario y mantener una lista de pasos de lectura pasados ​​a largo plazo para varios libros.
Pero al final, ¿vale la pena demorar el tiempo que lleva hacerlo en solo leer el libro?

---

Todos amaríamos mejores indicadores. Pero tal como está, probablemente tendremos que cumplir con estimaciones aproximadas, al menos hasta que las computadoras comiencen a obtener algoritmos estandarizados mejorados, y sean expertos en sopesar "inteligentemente" y anticipar factores dinámicos (como sus formas).

Y la barra de progreso en eso puede estar atascada en 5% en este momento. Solo tendremos que ver cómo va eso 8-)

Agregaría a la respuesta de @ gnasher729 que esta es otra consecuencia oculta de la indecidibilidad del problema de detención.

Dejando a un lado la imprevisibilidad inherente de los cálculos interactivos, incluso aquellos que pueden aislarse pueden tener un tiempo de ejecución (y "ritmo"), cuya previsibilidad no puede ser abordada por un método general.

Lamentablemente, una barra de progreso es a menudo una metáfora inútil. ¿Cuáles serían las alternativas? Si el usuario es consciente de lo que está sucediendo "bajo el capó", puede ser una opción agregar información semántica a la interfaz, haciendo la transición a una ejecución de modo de seguimiento. Si no, creando una atmósfera tranquila que reduzca las expectativas.

Educar al usuario para que comprenda nuestras limitaciones es una tercera opción a largo plazo.

Las barras de progreso se dibujan en función del número de subtareas completadas en lugar del tiempo transcurrido / requerido para completarlas.

Por ejemplo, suponga que una operación X tiene cuatro subpasos diferentes, al final de cada paso aumenta la barra de progreso en un 25%. Si un paso demora más en ejecutarse, es probable que vea el comportamiento que describió: 1 a 90% de una vez y horas para el resto.

La lógica detrás del uso del número de subtareas como una unidad en lugar de tiempo es que este último es impredecible. Incluso en el caso de descargar un archivo, la conexión puede caerse, por lo tanto, el tiempo no puede usarse como una unidad. Preferiría usar la cantidad de bytes descargados y no el tiempo requerido como unidad de progreso.