Tabla de contenidos
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 necesita hacer de antemano … ¿verdad?
En su mayor parte, es cierto que el algoritmo de origen sabe lo que necesita hacer de antemano. Sin embargo, precisar el tiempo que llevará realizar cada paso es una tarea muy difícil, si no virtualmente imposible.
No todas las tareas 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 se calcula simplemente como Tareas completadas / Número total de tareas . Si bien esto tiene 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:
- Crea una estructura de carpetas.
- Descomprima y copie 1 GB de archivos.
- Crea entradas de registro.
- Crea entradas del 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 algo de tiempo. Por lo tanto, una barra de progreso que funcione con un conteo simple saltará al 25% muy rápidamente, se detendrá un poco mientras el paso 2 está funcionando y luego saltará al 100% casi de inmediato.
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 el porcentaje de progreso real en lo que respecta al tiempo restante.
Para solucionar este problema, algunas barras de progreso pueden usar implementaciones en las que los pasos están ponderados. Considere los pasos anteriores donde se asigna un peso relativo a cada paso:
- Crea una estructura de carpetas. [Peso = 1]
- Descomprima y copie 1 GB de archivos. [Peso = 7]
- Crea entradas de registro. [Peso = 1]
- Crea entradas del menú de inicio. [Peso = 1]
Con 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 10% al finalizar y el paso 2 moviéndola 70%. Aunque ciertamente no es perfecto, 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 pasados no garantizan el rendimiento futuro
Considere un ejemplo simple de mí pidiéndole que cuente hasta 50 mientras uso un cronómetro para cronometrarlo. Digamos que cuenta 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 rastrea esto mostraría un 50% completo con 10 segundos restantes.
Sin embargo, una vez que tu cuenta llega a 25, empiezo a lanzarte pelotas de tenis. Probablemente, esto romperá su ritmo ya que su concentración ha pasado de contar números estrictamente a esquivar las bolas que se le lanzan. Suponiendo que pueda seguir contando, su ritmo ciertamente se ha ralentizado 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 ya sea parado o subiendo más alto.
Para obtener 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 en el 75% del camino, se produce una congestión en la red y la tasa de descarga cae 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 (usando solo el estado actual: Tamaño restante / Velocidad de descarga ) o, lo más probable, el navegador usa un algoritmo de promedio móvil que se ajusta a las fluctuaciones en la velocidad de transferencia sin mostrar saltos dramáticos al usuario.
Un ejemplo de un algoritmo continuo con respecto a la descarga de un archivo podría funcionar así:
- La velocidad de transferencia de los 60 segundos anteriores se recuerda con el valor más nuevo reemplazando al más antiguo (por ejemplo, el valor 61 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 (en aras de la simplicidad, usaremos 1 MB = 1,000 KB):
- A los 75 segundos de la descarga, nuestros 60 valores recordados serían cada uno de 1000 KB. La tasa de transferencia efectiva es de 1,000 KB (60,000 KB / 60), lo que arroja un tiempo restante de 25 segundos (25,000 KB / 1,000 KB).
- A los 76 segundos (donde la velocidad de transferencia cae a 500 KB), la velocidad de descarga efectiva se convierte en ~ 992 KB (59.500 KB / 60), lo que arroja un tiempo restante de ~ 24.7 segundos (24.500 KB / 992 KB).
- A los 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 los 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 que el patrón emerge aquí a medida que la caída en la velocidad de descarga se incorpora lentamente al promedio que se usa para estimar el tiempo restante. Con 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 (excepto por un estancamiento muy pequeño en la cuenta regresiva del tiempo estimado).
Llegar a los puntos clave: esta es simplemente una metodología para transmitir información al usuario final sobre 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 a pedido como en segundo plano, es casi imposible saber qué recursos del sistema estarán disponibles en cualquier momento en el futuro, y es la disponibilidad de los recursos del sistema lo que se necesita para completar cualquier tarea.
Con otro ejemplo, suponga que está ejecutando una actualización de programa en un servidor que realiza una actualización de 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 gravaría el rendimiento del almacenamiento, lo que también afectaría el rendimiento. O podría iniciarse una tarea programada que realiza un proceso de memoria intensiva. Entiendes la idea.
Como, quizás, una instancia más realista para un usuario común: considere ejecutar Windows Update o un análisis de virus. Ambas operaciones realizan operaciones intensivas en recursos en segundo plano. Como resultado, el progreso de cada uno depende de lo que esté haciendo el usuario 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 la barra de progreso se mueva de manera constante. Por otro lado, si está editando 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 propio sistema sabe a qué carga estará en cualquier momento en el futuro.
Al final, 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á bloqueado. Es bueno 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 dedicar tiempo.
Por supuesto, tiene todo el derecho a sentirse molesto cuando una barra de progreso salta al 99% de forma instantánea y luego le hace esperar 5 minutos para el uno por ciento restante. Pero si el programa respectivo funciona bien en general, recuerde que el desarrollador tenía claras sus prioridades.