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

8

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?

Paul Uszak
fuente
1
Esto no tiene nada que ver con el equipo de ciencia .
Raphael
1
Traté de acercarlo a un marco científico en mi respuesta. Pobre de mí.
André Souza Lemos
@Raphael Obviamente, los 5 lectores que publicaron respuestas difieren de su opinión. No se trata de locomoción a vapor, ¿verdad?
Paul Uszak
No, se trata de fallas en el diseño de la interfaz de usuario. Lo cual es offtopic. No puede haber preguntas de informática de allí, pero no en su forma actual. (Tenga en cuenta que su suposición es sutilmente defectuosa. Si bien las computadoras reales son predecibles, estrictamente hablando, calcular una predicción en general no es más barato que el cálculo en sí. Además, ¿quién hace la predicción? Las aplicaciones no controlan la máquina, por lo que cualquier predicción es predicado sobre la suposición de "Obtendré tantos recursos como he estado obteniendo", ¡en absoluto una suposición sólida!)
Raphael

Respuestas:

2

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)

usuario6916458
fuente
1
Gracias por su respuesta. Me gustaría animar a verificar si la pregunta es sobre el tema primero.
Mal
@Evil, por desgracia, la versión móvil de SO no había actualizado que la pregunta fue votada como fuera de tema cuando escribí esta respuesta.
user6916458
3

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.

gnasher729
fuente
3

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-)

Tempestad de peligro
fuente
1
Gracias por su respuesta. Me gustaría animar a verificar si la pregunta es sobre el tema antes de responder.
Mal
Gracias por molestarse en responder mi pregunta de manera tan completa, simplemente ignore el comentario anterior del Dr. Evil.
Paul Uszak el
1
La analogía de tu libro es buena y mala. Sí, es como leer un libro, pero no olvides que el libro ya ha sido leído (por los desarrolladores). Debería ser posible producir una especie de mapa de ejecución, declaraciones de hitos o procedimientos críticos completados y luego enviarlo al usuario. Me estoy centrando en el software comercial que ya ha sido marcado para cosas como el rendimiento de todos modos. Si puede comparar el rendimiento operativo / asignación de recursos, se deduce que debería poder comparar el rendimiento de la instalación si el algoritmo se ha ejecutado anteriormente.
Paul Uszak el
1

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.

André Souza Lemos
fuente
1
Tengo que hacer una excepción a su caracterización de usuario . Un usuario podría estar actualizando la suite Oracle Enterprise Business para un banco comercial que no es como instalar Space Invaders. Mostrar una barra de progreso no está ahí para reducir las expectativas. pero para retroalimentar al equipo del proyecto cuánto tiempo estará inactivo el sistema comercial. Y no estoy seguro de si este es un ejemplo del problema de detención, ya que un banco podría no querer comenzar una actualización que no está garantizada para completar ...
Paul Uszak
1
No veo ninguna razón por la cual este fenómeno, en general, deba atribuirse a la integridad de Turing. Muchos procesos que requieren barras de progreso son secuencias finitas de subprocesos que definitivamente terminan.
Rhymoid
1
La cantidad de veces que un subprograma tendrá que ejecutarse es una propiedad no trivial de la ejecución de un programa, que afecta su tiempo estimado de finalización. El teorema de Rice muestra que estos son problemas indecidibles, por reducción al problema de detención. Concretamente, modelar el comportamiento de un programa con tanto detalle como para hacer que una barra de progreso sea fiel a lo que realmente está sucediendo generalmente no es factible, por razones prácticas.
André Souza Lemos
@PaulUszak ¿Cuántas veces hemos estado esperando desesperadamente que finalicen los programas (actualizaciones, lo que sea)? ¿Gente, bancos, pilotos de aviones, gobiernos ...?
André Souza Lemos
@ AndréSouzaLemos Eso está completamente fuera del punto. Esta es una pregunta sobre una observación sobre la práctica. En la práctica, el número de veces que el subprograma tendrá que ejecutarse se conoce dentro de un límite estrecho, mientras que el tiempo para dedicarlo generalmente no se conoce de antemano porque depende de la E / S. La lógica detrás de las barras de progreso siempre se crea para aplicaciones específicas, y no se genera a través del análisis de programas o alguna otra cosa en la que la teoría de la computabilidad pueda volver atrás.
Rhymoid
1

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.

Codificadores extremos
fuente
1
Gracias por su respuesta. Me gustaría animar a verificar si la pregunta es sobre el tema primero.
Mal