language agnostic - Estimaciones de tiempo realistas para barras de progreso, etc.
language-agnostic statistics (7)
¡Gracias a Dios que no soy el único!
No conozco una biblioteca que maneje la estimación, pero personalmente puedo responder por sus ideas de creación de perfiles. Una vez implementé una barra de progreso que se usó para informar el progreso de una operación de archivo larga y complicada (se estaban leyendo, procesando y combinando varios archivos pequeños en un archivo más grande). Hice que el software mantuviera un registro del tiempo que tomaba para leer, escribir y procesar, y luego ajusté la barra de progreso en consecuencia. Después de que el programa se ejecutó un par de veces, la barra de progreso se movería tan suave como la seda. Sin pausas y sin bips rápidos.
Esto funciona siempre que el tiempo necesario para sus operaciones se pueda medir fácilmente. Me desconfiaría de usar este método en algo como un indicador de progreso de descarga, ya que la velocidad de la red es completamente indeterminada.
Sé que no soy el único a quien no le gustan las barras de progreso o las estimaciones de tiempo que dan estimaciones no realistas en software. Los mejores ejemplos son los instaladores que saltan del 0% al 90% en 10 segundos y luego toman una hora para completar el 10% final.
La mayoría de las veces, los programadores solo estiman los pasos para completar una tarea y luego muestran el paso de paso / total actual como un porcentaje, ignorando el hecho de que cada paso puede tomar un tiempo diferente para completarse. Por ejemplo, si inserta filas en una base de datos, el tiempo de inserción puede aumentar con el número de filas insertadas (ejemplo sencillo), o el tiempo para copiar archivos no solo depende del tamaño del archivo sino también de la ubicación en la base de datos. El disco y lo fragmentado que está.
Hoy, me pregunté si alguien ya había intentado modelar esto y quizás creó una biblioteca con un estimador robusto configurable . Sé que es difícil dar estimaciones sólidas porque los factores externos (conexión de red, usuario ejecuta otros programas, etc.) hacen su parte.
Tal vez también exista una solución que utilice la creación de perfiles para configurar un mejor estimador, o se podrían usar enfoques de aprendizaje automático.
¿Alguien sabe de soluciones avanzadas para este problema?
En relación con esto, encontré el artículo Repensando la barra de progreso muy interesante. Muestra cómo las barras de progreso pueden cambiar la percepción del tiempo y cómo puede usar esas ideas para crear barras de progreso que parecen ser más rápidas.
EDITAR : Puedo pensar en maneras de ajustar manualmente el tiempo estimado, e incluso con una ''biblioteca de estimadores'' tendré que ajustar el algoritmo. Pero creo que este problema podría ser abordado con herramientas estadísticas. Por supuesto, el estimador recopilaría datos durante el proceso para crear mejores estimaciones para los próximos pasos.
Lo que hago ahora es tomar el tiempo promedio que tomó el paso anterior (pasos agrupados por tipo y normalizado por ejemplo, tamaño de archivo, tamaño de transacción) y tomar este promedio como estimación para los siguientes pasos (nuevamente: contar en diferentes tipos y tamaños).
Ahora, sé que hay mejores herramientas estadísticas para crear estimadores y me pregunto si alguien aplicó esas al problema.
Como usted dice, puede tener 100 pasos pero cada uno de esos pasos tomará una cantidad diferente de tiempo dependiendo de lo que hagan.
Un enfoque sería agrupar las tareas por lo que están haciendo (eliminar, cambiar los valores del registro, descargar, copiar archivos, etc.) y, para cada grupo, asignar algunas propiedades clave:
- ¿Qué métricas controlables se aplican (velocidad de copia, velocidad de desempaque, etc.)?
- ¿Cuál es la tasa promedio de peor caso para ese proceso?
Luego, debe crear una lista de lo que va a hacer para todo el trabajo, por ejemplo:
- Desempaquetar un archivo 100meg (grupo: desempaquetar, valor: 100)
- Copiando 120megs (grupo: copia, valor: 120)
- Configuración de valores de registro (grupo: registro, valor: 25)
- Limpiar (grupo: borrado, valor: 100)
De este modo, puede elaborar una "estimación" general basada en sus valores promedio de peor caso predeterminados, pero la clave de la precisión es actualizar cada multiplicador de métricas a medida que aprende qué tan rápido el sistema puede realizar cada tarea.
Le tomó a Microsoft una década para hacerlo bien, así que no te angusties si no funciona al principio =)
El problema con el uso de una barra de progreso es a menudo un proceso que toma varios pasos diferentes. Entonces, si estuviera haciendo un diálogo de progreso para una actualización de software, no usaría una sola barra de progreso, sino una lista de tareas con marcas de verificación para que el usuario pueda ver qué tarea se está realizando en este momento.
Ponga una barra de progreso junto a la tarea si tarda más de 10 segundos para que puedan ver que se está trabajando y no lo abortan demasiado pronto.
Descarga de la actualización
Dejar de ejecutar procesos
Actualiza el software
Configurar software
Programa de reinicio
Las tareas individuales son agradables porque el rendimiento pasado indica fuertemente el rendimiento futuro. Los primeros 10 segundos de la descarga probablemente le mostrarán cuánto tiempo lleva el resto del archivo. Lo mismo con la actualización en sí.
Los procesos más cortos no necesitan una barra de progreso, así que ni siquiera muestres una en ningún proceso hasta que ese proceso haya tomado 10 segundos o más. De esa manera, el usuario en un sistema rápido simplemente ve una marca de verificación en cada tarea, y en un sistema lento el usuario ve las marcas de verificación, y si permanece en una tarea "demasiado larga" obtiene la barra de progreso con información realmente útil.
Y la barra de progreso no hace ninguna promesa sobre cuánto tardarán las tareas posteriores.
Tener un "tiempo estimado total" en la parte inferior que cubra la mejor estimación para todas las tareas es muy útil, pero no lo mostraría en una barra de progreso.
Lo que pasa con las barras de progreso es que están destinados a viajar linealmente. Cuando saltan y tartamudean, es muy frustrante para el usuario: en realidad son menos útiles y dan la información incorrecta en ese caso.
Elija la herramienta adecuada para el trabajo. Demasiadas veces se elige una barra de progreso cuando en realidad es la herramienta incorrecta.
-Adán
Estoy usando DREJ para hacer regresión no lineal de mínimos cuadrados en el progreso histórico. Funciona bastante bien.
Utilizo una tabla de base de datos para almacenar mis datos históricos. Reconstruyo mi función de estimador en base a las últimas 100 entradas en la tabla.
Tengo anotaciones sobre métodos de larga ejecución para identificar la variable determinante de la velocidad.
YMMV, pero la próxima vez que la estimación lo tenga en cuenta.
Mientras estudiaban, Julian Missig y yo hicimos un experimento no muy diferente al de Harrison et al. papel. Como era de esperar para un proyecto de clase, realmente no obtuvimos suficientes datos para hacer afirmaciones sólidas, excepto que para un intervalo de 5 segundos, la barra de progreso no se percibió como más corta .
Por lo tanto, si es probable que la tarea tarde más de 10 segundos, es mejor no mostrar una barra de progreso. Eso no quiere decir que no deba mostrar ningún comentario, pero es probable que una barra de progreso haga que parezca más lento.
Si estás interesado, Julian tiene el paper y el poster en su sitio.
No creo que el problema sea que estimen la cantidad de pasos tanto que es que a menudo se usa la definición incorrecta de "paso". En su ejemplo de que el instalador va del 0 al 9% en 10 segundos y luego una hora para el resto, he visto que eso sucede cuando el programador decidió contar la cantidad de archivos que copiar, no la cantidad de bytes.
Digamos que había 10 archivos, 9 de ellos eran 5K cada uno (readme, licencia, icono, etc.) y el último era un 2Gig ISO, bueno, ¡los primeros 9 se copiarían muy rápido y el último sería lento! Contar los archivos no era lo correcto, debería haber contado bytes. El problema es que si desea contar bytes, entonces necesita implementar su propia rutina de copia para poder proporcionar actualizaciones de estado durante la copia del archivo grande. ¿Realmente vale la pena implementar tu propia rutina de copia?
El otro problema es que una instalación (como muchas otras cosas) está formada por pilas de rutinas que pueden ser bastante profundas. Estas rutinas pueden hacer muchas cosas, pero probablemente son rutinas genéricas, y no tienen nada que sea capaz de actualizar un medidor de progreso a un nivel mucho más alto. Necesitará volver a implementar una serie de rutinas comunes para obtener una buena información de progreso.
En cuanto a un estimador robusto, creo que sería muy difícil. Los pasos particulares podrían definirse en un archivo de configuración, pero necesitaría actualizaciones de progreso de cada parte del proceso de instalación. Además, el tiempo para hacer estas cosas obviamente variaría de una máquina a otra, por lo que es probable que esté muy lejos. Por supuesto, una vez que haya realizado la instalación en una máquina específica, es probable que pueda estimar la instalación en esa máquina la próxima vez. ;-)
Otra forma (y mucho más simple) es simplemente rellenar la estimación y la percepción del usuario.
La mayoría de las barras de progreso tienen más que ver con la capacidad de respuesta de la interfaz de usuario que con la predicción de la duración: el usuario necesita comentarios que confirmen que el programa no está bloqueado, pero no le importa mucho el tiempo de finalización.
Si estoy esperando por una tarea, y se completa al 50% en 10 segundos, me siento frustrado cuando se necesitan otros 20 segundos para completar el último 50%.
Para la misma tarea, si va al 50% en 30 segundos, continúa hasta el 60%, y luego salta mágicamente al 100%. Me sorprende, pero no me molesta.
Si la tarea es realmente corta o completamente impredecible, algunos bucles animados también funcionan (icono de carga del navegador, animación de espera del iPhone, etc.).
Si está en el par de casos en los que realmente necesita precisión, entonces probablemente valga la pena dedicar algo de tiempo al código para una mejor confiabilidad de la barra.