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.
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:
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:
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.
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í:
Entonces, usando nuestro escenario anterior (en aras de la simplicidad, usaremos 1 MB = 1,000 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 …
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.
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.
El mundo del gaming ha experimentado un crecimiento exponencial en los últimos años. La…
Stokkete/Shutterstock.com ¿Sigue utilizando una unidad flash USB obsoleta para almacenar sus archivos? ¿Por qué no…
LG Los fabricantes siempre intentan mejorar el rendimiento de imagen de los monitores. Como resultado,…
Patty Chan/Shutterstock.com Si cree en lo que ve en las redes sociales, puede pensar en…
Seksan.TH/Shutterstock.com Los servicios de suscripción como Netflix, Game Pass y Spotify nos permiten consumir tantas…
fatmawati achmad zaenuri/Shutterstock El acceso a Internet, oa cualquier otra red, se rige por la…