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

A primera vista, parece que generar una estimación precisa del tiempo debería ser bastante fácil. Después de todo, el algoritmo que produce la barra de progreso conoce todas las tareas que debe hacer antes de tiempo ...?

En su mayor parte, es cierto que el algoritmo de origen sabe lo que necesita hacer antes de tiempo. Sin embargo, determinar el tiempo que tomará realizar cada paso es una tarea muy difícil, si no virtualmente imposible..

Todas las tareas no son iguales

La forma más sencilla de implementar una barra de progreso es utilizar una representación gráfica del contador de tareas. Donde el porcentaje completado simplemente se calcula como Tareas completadas / Número total de tareas. Si bien esto tiene un sentido lógico a primera vista, es importante recordar que (obviamente) algunas tareas tardan más en completarse.

Considere las siguientes tareas realizadas por un instalador:

1. Crear estructura de carpetas.
2. Descomprime y copia 1 GB de archivos.
3. Crear entradas de registro.
4. Crear entradas de menú de inicio..

En este ejemplo, los pasos 1, 3 y 4 se completarían muy rápidamente, mientras que el paso 2 tomaría algún tiempo. Por lo tanto, una barra de progreso que funcione en un conteo simple saltará a 25% muy rápidamente, se detendrá un poco mientras el paso 2 está funcionando, y luego saltará a 100% casi inmediatamente.

Este tipo de implementación es bastante común entre las barras de progreso porque, como se indicó anteriormente, es fácil de implementar. Sin embargo, como puede ver, está sujeto a tareas desproporcionadas que sesgan la real porcentaje de progreso en relación con el tiempo restante.

Para evitar esto, algunas barras de progreso pueden usar implementaciones donde los pasos se ponderan. Considere los pasos anteriores donde se asigna un peso relativo a cada paso:

1. Crear estructura de carpetas. [Peso = 1]
2. Descomprime y copia 1 GB de archivos. [Peso = 7]
3. Crear entradas de registro. [Peso = 1]
4. Crear entradas de menú de inicio. [Peso = 1]

Usando este método, la barra de progreso se movería en incrementos del 10% (ya que el peso total es 10) con los pasos 1, 3 y 4 moviendo la barra un 10% al finalizar y el paso 2 moviéndolo un 70%. Si bien ciertamente no son perfectos, métodos como este son una forma sencilla de agregar un poco más de precisión al porcentaje de la barra de progreso.

Los resultados anteriores no garantizan el rendimiento futuro

Considera un ejemplo simple en el que te pido que cuentes hasta 50 mientras uso un cronómetro para cronometrarte. Digamos que cuentas hasta 25 en 10 segundos. Sería razonable suponer que contará los números restantes en 10 segundos adicionales, por lo que una barra de progreso que muestre el 50% se completará con 10 segundos restantes.

Sin embargo, una vez que tu cuenta llega a 25, empiezo a lanzarte pelotas de tenis. Probablemente, esto romperá tu ritmo ya que tu concentración ha pasado de contar estrictamente los números a esquivar las bolas lanzadas en tu camino. Suponiendo que pueda continuar contando, su ritmo ciertamente se ha desacelerado un poco. Así que ahora la barra de progreso todavía se está moviendo, pero a un ritmo mucho más lento con el tiempo estimado restante parado o en realidad subiendo más.

Para un ejemplo más práctico de esto, considere la posibilidad de descargar un archivo. Actualmente está descargando un archivo de 100 MB a una velocidad de 1 MB / s. Esto es muy fácil de determinar el tiempo estimado de finalización. Pero el 75% del camino allí, algunos congestionamientos de red y su tasa de descarga se reduce a 500 KB / s.

Dependiendo de cómo el navegador calcule el tiempo restante, su ETA podría pasar instantáneamente de 25 segundos a 50 segundos (utilizando el estado actual solamente: Tamaño restante / velocidad de descarga) o, lo más probable, el navegador utiliza un algoritmo de promedio variable que se ajustaría a las fluctuaciones en la velocidad de transferencia sin mostrar saltos dramáticos al usuario.

Un ejemplo de un algoritmo rodante con respecto a la descarga de un archivo podría funcionar de la siguiente manera:

• La velocidad de transferencia de los 60 segundos anteriores se recuerda con el valor más reciente que reemplaza al más antiguo (por ejemplo, el valor 61st reemplaza al primero).
• La tasa de transferencia efectiva para el cálculo es el promedio de estas mediciones..
• El tiempo restante se calcula como: Tamaño restante / velocidad de descarga efectiva

Entonces, usando nuestro escenario anterior (para simplificar, usaremos 1 MB = 1,000 KB):

• A los 75 segundos de la descarga, nuestros 60 valores recordados serían de 1.000 KB. La tasa de transferencia efectiva es de 1.000 KB (60.000 KB / 60), lo que da un tiempo restante de 25 segundos (25.000 KB / 1.000 KB).
• A los 76 segundos (donde la velocidad de transferencia se reduce a 500 KB), la velocidad de descarga efectiva se convierte en ~ 992 KB (59,500 KB / 60), lo que da un tiempo restante de ~ 24.7 segundos (24,500 KB / 992 KB).
• A 77 segundos: velocidad efectiva = ~ 983 KB (59,000 KB / 60), lo que da un tiempo restante de ~ 24.4 segundos (24,000 KB / 983 KB).
• A 78 segundos: velocidad efectiva = 975 KB (58,500 KB / 60), lo que da un tiempo restante de ~ 24.1 segundos (23,500 KB / 975 KB).

Puede ver el patrón emergente aquí a medida que la disminución de la velocidad de descarga se incorpora lentamente al promedio que se utiliza para estimar el tiempo restante. Bajo este método, si la caída solo duró 10 segundos y luego regresó a 1 MB / s, es poco probable que el usuario note la diferencia (ahorre para un puesto muy pequeño en la cuenta regresiva del tiempo estimado).

Llegar a las tachuelas: esta es simplemente una metodología para transmitir información al usuario final por la causa subyacente real ...

No se puede determinar con precisión algo que no es determinista

En última instancia, la inexactitud de la barra de progreso se reduce al hecho de que está tratando de determinar un momento para algo que no es determinista. Debido a que las computadoras procesan tareas tanto en la demanda como en segundo plano, es casi imposible saber qué recursos del sistema estarán disponibles en cualquier momento en el futuro, y lo que se necesita para completar cualquier tarea es la disponibilidad de los recursos del sistema..

Usando otro ejemplo, suponga que está ejecutando una actualización del programa en un servidor que realiza una actualización de la base de datos bastante intensiva. Durante este proceso de actualización, un usuario envía una solicitud exigente a otra base de datos que se ejecuta en este sistema. Ahora, los recursos del servidor, específicamente para la base de datos, tienen que procesar solicitudes tanto para su actualización como para la consulta iniciada por el usuario, un escenario que sin duda será mutuamente perjudicial para el tiempo de ejecución. Alternativamente, un usuario podría iniciar una solicitud de transferencia de archivos de gran tamaño que pondría a prueba el rendimiento del almacenamiento, lo que también reduciría el rendimiento. O podría comenzar una tarea programada que realice un proceso intensivo de memoria. Tienes la idea.

Como, quizás, una instancia más realista para un usuario cotidiano, considere ejecutar Windows Update o un análisis de virus. Ambas operaciones realizan operaciones intensivas de recursos en segundo plano. Como resultado, el progreso de cada uno depende de lo que el usuario esté haciendo en ese momento. Si está leyendo su correo electrónico mientras se ejecuta, lo más probable es que la demanda de recursos del sistema sea baja y que la barra de progreso se mueva de manera constante. Por otro lado, si está realizando la edición de gráficos, su demanda de recursos del sistema será mucho mayor, lo que hará que el movimiento de la barra de progreso sea esquizofrénico..

En general, es simplemente que no hay bola de cristal. Ni siquiera el sistema en sí sabe a qué carga estará en algún momento en el futuro..

En última instancia, realmente no importa

La intención de la barra de progreso es, bueno, indicar que efectivamente se está progresando y que el proceso respectivo no está colgado. Es agradable cuando el indicador de progreso es preciso, pero normalmente es solo una pequeña molestia cuando no lo es. En su mayor parte, los desarrolladores no van a dedicar mucho tiempo y esfuerzo a los algoritmos de la barra de progreso porque, francamente, hay tareas mucho más importantes en las que invertir tiempo..

Por supuesto, tiene todo el derecho de estar molesto cuando la barra de progreso salta al 99% al instante y luego le hace esperar 5 minutos hasta el uno por ciento restante. Pero si el programa respectivo funciona bien en general, recuerde que el desarrollador tenía sus prioridades correctas.