L'affichage d'une barre de progression entraîne un temps d'exécution plus lent

Question

J'écris beaucoup de scripts internes qui automatisent les tâches d'une équipe. Afin de les empêcher de se demander si le script s'est "arrêté", j'affiche une barre de progression simple pour les tâches de longue durée. Je fais cela parce que je peux mesurer le montant terminé car je connais le montant à compléter avant de courir. Pour économiser sur le nombre d'opérations en cours, je ne mets à jour la barre de progression que toutes les nsecondes ou lorsque la tâche est lancée / terminée.

Ce que j'ai trouvé, c'est qu'il y a un compromis entre:

• expérience utilisateur (sachant que la tâche est en cours)
• heure de fin du script global

En ajoutant des étapes pour produire une barre de progression et les tenir au courant, une tâche peut prendre deux fois plus de temps.

En général, est-ce un compromis attendu (peut-être pas dans d'autres langages, mais en Python)?

Answer 1

C'est une très belle question.

En général, nous accordons toujours la priorité à l'expérience utilisateur.

Exemple: les moteurs de recherche de vols peuvent fournir des résultats instantanément, mais leur chargement est plus long car les utilisateurs se sentent plus sûrs d'avoir effectué une recherche approfondie.

Quand il s'agit de 2x fois plus lent. 2x est probablement ok quand c'est quelques secondes et est probablement terrible si c'est pendant des années. Tout dépend du contexte de vos utilisateurs. Si le type de travail de votre site est une question de vie ou de mort, alors le plus rapide est mieux, si vos utilisateurs sont plus détendus avec le temps qu'il faut et il est plus important pour eux de savoir quand revenir, puis de leur dire l'heure prévue. la meilleure option.

Accélérez quand

• Il est prouvé que le temps de chargement a un impact négatif sur l'adoption, l'utilisation, la fiabilité, la confiance, etc.
• La vitesse est une question de vie ou de mort
• La vitesse est une question de gagner de l'argent (par exemple, les clients au téléphone ont besoin d'une réponse urgente)

Afficher la barre de chargement si

• Multiplier le temps par deux ne crée pas un temps qui dissuaderait complètement les utilisateurs
• Vos utilisateurs peuvent se permettre d'attendre en faisant probablement autre chose

Autres éléments à prendre en compte Peut-être avez-vous besoin d'une solution hybride qui, pour certains processus, vous donne la barre de chargement et pour certains, non.

Peut-être avez-vous besoin d'options alternatives: par exemple, afficher la barre de chargement et dire aux utilisateurs qu'en la masquant, ils peuvent accélérer la tâche, demander aux utilisateurs s'ils souhaitent recevoir une notification par e-mail lorsque la tâche est prête, etc.

Dans tous les cas, la meilleure idée serait de voir ce que les utilisateurs préféreraient en fonction de leur contexte et de leurs besoins.

Bonne chance, c'est un défi très intéressant. Publiez la décision que vous avez prise à la fin. :)

Answer 2

Trivialement, tout programme qui fait une action plus montrant une barre de progression (donc deux actions) utilisera plus de CPU qu'un seul faisant une seule action.

Cependant, cela ne signifie pas qu'il devrait être nécessairement plus lent dans l'heure de l'horloge murale. En fait, un ralentissement 2x à mon avis semble exagéré.

Certaines stratégies comprennent:

• Ne pas afficher de barre de progression (whis est en fait la valeur par défaut pour la plupart des commandes Unix, où vous auriez besoin d'ajouter une option détaillée)
• Fournir une option silencieuse pour désactiver la barre de progression. Cela devrait en fait être fourni pour l'interface utilisateur (par exemple, supposons que l'utilisateur l'exécutera à partir de cron, ou redirigera la sortie vers un fichier), mais aurait pour effet secondaire de contourner le ralentissement de la barre de progression.
• Montrant la progression à travers un fil différent. Probablement complexe à réaliser avec python, mais normal avec d'autres langages. Vous avez un thread GUI vous montrant une certaine progression, et un ouvrier effectuant le travail réel.
• Réduction de l'intervalle de mise à jour de la barre de progression / de la taille des pas.
  • Si vous copiez un fichier octet par octet (pour le bien de l'argument, c'est évidemment inefficace), plutôt que de redessiner la barre de progression à chaque octet, vous voudrez peut-être la mettre à jour uniquement après chaque Mo copié.
  • Ou par le temps passé, comme la définition d'une minuterie qui mettrait à jour l'état toutes les X secondes (encore une fois, de préférence asynchrone à l'action principale, ou sur un thread différent).
• En rendant la barre de progression aussi bon marché que possible. Cela peut aller de la simple sortie de points plutôt que d'une barre de progression à part entière jusqu'à ce que la barre de progression soit "dessinée", et en évitant de la calculer à nouveau à chaque étape (vous devez cependant effectuer le traitement complet sur SIGWINCH)

En général, est-ce un compromis attendu

En général, je pense que cela dépend s'il est possible de l'éviter ou non. Si nous téléchargeons un gros fichier à partir d'Internet, vous pouvez presque toujours installer une barre de progression appropriée, car le téléchargement utilisera différentes ressources. Si vous souhaitez copier des fichiers à partir d'un système de fichiers distant et lent (tel qu'un smartphone), la navigation dans toute l'arborescence de répertoires qui devra être copiée pour qu'une barre de progression puisse apparaître 7 nécessitera probablement des ressources (la bande passante de la connexion avec le téléphone) qui pourraient être ignorés si des fichiers étaient trouvés et copiés "tels qu'ils apparaissent".