Mostrar una barra de progreso da como resultado un tiempo de finalización más lento
Escribo muchos scripts internos que automatizan las tareas de un equipo. Para evitar que se pregunten si el script se ha "detenido", muestro una barra de progreso simple para las tareas de larga ejecución. Hago esto porque puedo medir la cantidad completada ya que sé la cantidad que debe completarse antes de ejecutar. Para ahorrar en la cantidad de operaciones que se realizan, solo actualizo la barra de progreso cada nsegundo o cuando la tarea se inicia / completa.
Lo que he encontrado es que existe una compensación entre:
- experiencia del usuario (saber que la tarea se está ejecutando)
- tiempo de finalización del guión general
Al agregar pasos para producir una barra de progreso y mantenerlos al tanto, una tarea puede tomar el doble de tiempo.
En general, ¿es esta una compensación esperada (quizás no en otros lenguajes, pero en Python)?
Respuestas
Esa es una pregunta muy bonita.
En general, siempre damos prioridad a la experiencia del usuario.
Ejemplo: los motores de búsqueda de vuelos pueden ofrecer resultados instantáneamente, pero tienen una carga más larga ya que los usuarios se sienten más seguros de haber realizado una búsqueda completa.
Cuando se trata de 2x veces más lento. 2x probablemente esté bien cuando sea un par de segundos y probablemente sea terrible si lo es durante años. Todo depende del contexto de sus usuarios. Si el tipo de trabajo de su sitio es un asunto de vida o muerte, entonces más rápido es mejor, si sus usuarios están más relajados con el tiempo que lleva y es más importante que sepan cuándo volver a consultar, entonces decirles el tiempo esperado sería la mejor opción.
Hazlo más rápido cuando
- Se ha demostrado que el tiempo de carga tiene un impacto negativo en la adopción, el uso, la confiabilidad, la confianza, etc.
- La velocidad es cuestión de vida o muerte
- La velocidad es una cuestión de ganar dinero (por ejemplo, los clientes en el teléfono necesitan una respuesta urgente)
Muestre la barra de carga si
- Multiplicar el tiempo por dos no crea un tiempo que desanime por completo a los usuarios
- Los usuarios pueden permitirse esperar mientras probablemente hacen otra cosa
Más cosas a tener en cuenta Tal vez necesite una solución híbrida que para algunos procesos obtenga la barra de carga y para otros, no.
Tal vez necesite opciones alternativas: por ejemplo, mostrar la barra de carga y decirle a los usuarios que al ocultarla pueden acelerar la tarea, preguntar a los usuarios si desean recibir una notificación por correo electrónico cuando la tarea esté lista, etc.
En cualquier caso, la mejor idea sería ver qué preferirían los usuarios según su contexto y necesidades.
Sin embargo, buena suerte, es un desafío muy interesante. Publique la decisión que eligió al final. :)
Trivialmente, cualquier programa que esté realizando una acción más que muestre una barra de progreso (por lo tanto, dos acciones) utilizará más cpu que uno que realice una sola acción.
Sin embargo, esto no significa que deba ser necesariamente más lento en el tiempo del reloj de pared. De hecho, una desaceleración 2x en mi humilde opinión parece exagerada.
Algunas estrategias incluyen:
- No muestra una barra de progreso (whis es en realidad el valor predeterminado para la mayoría de los comandos de Unix, donde necesitaría agregar una opción detallada)
- Proporciona una opción silenciosa para desactivar la barra de progreso. En realidad, esto debería proporcionarse para la interfaz de usuario (por ejemplo, suponga que el usuario lo ejecutará desde cron o redirigirá la salida a un archivo), pero tendría el efecto secundario de evitar la ralentización de la barra de progreso.
- Mostrando el progreso a través de un hilo diferente. Probablemente complejo de realizar con Python, pero normal con otros lenguajes. Tiene un hilo de GUI que le muestra algunos avances y uno de trabajador que realiza el trabajo real.
- Reducir el intervalo de actualización de la barra de progreso / tamaño de paso.
- Si estuviera copiando un archivo byte a byte (por el bien del argumento, esto obviamente es ineficiente), en lugar de volver a dibujar la barra de progreso cada byte, es posible que desee actualizarlo solo después de cada MB copiado.
- O por el tiempo empleado, como configurar un temporizador que actualizaría el estado cada X segundos (nuevamente, preferiblemente asíncrono a la acción principal, o en un hilo diferente).
- Haciendo que la barra de progreso sea lo más barata posible. Esto podría pasar de solo generar puntos en lugar de una barra de progreso completa a tener la barra de progreso "dibujada" y evitar calcularla nuevamente en cada paso (aunque debe realizar el procesamiento completo en SIGWINCH)
En general, ¿se trata de una compensación esperada?
En general, creo que depende de si es posible evitarlo o no. Si estamos descargando un archivo grande de Internet, casi siempre puede ajustar una barra de progreso adecuada, ya que la descarga utilizará diferentes recursos. Si desea copiar archivos desde un sistema de archivos remoto y lento (como un teléfono inteligente), la exploración de todo el árbol de directorios que tendrá que copiarse para que se muestre una barra de progreso7 probablemente requerirá recursos (el ancho de banda de la conexión con el teléfono) que podrían omitirse si se encontraran archivos y se copiaran "tal como aparecen".