Pourquoi les barres de progression sont-elles si inexactes? [fermé]

Les ordinateurs et les langages de programmation ont tendance à être déterministes et prévisibles. Pourtant, les barres de progression semblent le contraire, surtout si l'opération est complexe. Même pour les produits professionnels de classe mondiale, certaines barres de progression ne reflètent pas vraiment la progression réelle d'une opération. Je les ai vu passer de 10% à 90% d'un bond après n'avoir rien fait pendant 4 heures. J'ai même vu certains reculer, suggérant qu'un traitement inattendu supplémentaire a été découvert.

Certes, il peut y avoir des opérations de base de données, le traitement du réseau et des opérations parallèles, mais il semble que cela pourrait être quantifié d'une certaine manière et un pourcentage estimé. Après tout, il doit y avoir une quantité finie d'instructions exécutées pour terminer une opération. Est-ce simplement un mauvais codage, ou y a-t-il une raison fondamentale pour laquelle le progrès est difficile?

Pour ajouter aux réponses plus générales jusqu'à présent, je peux donner quelques exemples de mon domaine où les barres de progression ne fonctionnent pas et pourquoi;

Programmes de conception assistée par ordinateur - les programmes qui effectuent l'analyse thermique ou la mécanique des fluides peuvent être généralement terribles avec des barres de progression. Ils sautent en avant, en arrière, prennent des mesures incohérentes et il est presque inutile de les regarder. Cela est dû à la nature itérative de ces types de simulations et à la nécessité de trouver une convergence. Ceci est mieux vu non pas par une barre de progression mais par un tracé d'itération contre convergence.

Simulations complexes - J'ai écrit un programme qui simule un environnement complexe avec de nombreux facteurs croisés. C'était pour une chronologie fixe, donc la barre de progression pourrait être le bon moment? Dans mon cas, la simulation est trop longue à chaque nouveau pas de temps, ce qui signifie que la barre de progression devient de plus en plus lente - pas terrible. J'ai trouvé une autre mesure pour combien de temps la simulation moyenne prend en fonction du nombre d'éléments dans la simulation qui était plus proche de la précision - mais pas idéal car parfois la barre de processus n'a jamais été remplie (simulation arrêtée auparavant) ou atteint 100% trop tôt (simulation exécutée plus longtemps que prévu).

Dans les deux cas, une barre complète de progression pure serait impossible de calculer le maximum pour au préalable (cas 1) ou pas linéaire et donc pas très utile (cas 2)

Tous les deux. Parfois, il est juste difficile d'estimer le temps qu'une opération prendra, car vous ne savez pas à l'avance combien de travail doit être fait. Parfois, ses estimations simplistes et inexactes.

Exemple: je télécharge quatre fichiers simultanément. Quelqu'un sait à quel point chaque fichier est volumineux, combien a été téléchargé et combien de mégaoctets par seconde ont été téléchargés pour chaque fichier. Semble facile de prévoir combien de temps cela prendra. Cependant, je sais qu'après le téléchargement d'un fichier, les autres se téléchargent plus rapidement. Encore plus après le téléchargement de 3 fichiers; le dernier téléchargera quatre fois plus vite. Je n'ai jamais vu de barre de progression en tenir compte.

Exemple: vous copiez un gros dossier. La barre de progression suppose que vous copiez X mégaoctets par seconde, sait combien de mégaoctets il y a et votre vitesse moyenne jusqu'à présent. Le problème est que "mégaoctets par seconde" est très imprécis - en pratique, cela prend x millisecondes par fichier, plus y millisecondes par mégaoctet. De nombreux petits fichiers prennent donc beaucoup plus de temps que ne le prévoit la barre de progression.

Le problème est que les développeurs de logiciels peuvent s'en soucier, mais leurs gestionnaires ne le font pas tant que votre ordinateur ne plante pas.

Je pense que la réponse globale est qu'il est souvent trop complexe (ou impossible) de calculer le temps qu'il faudra.

Parfois, il s'agirait simplement de réduire le temps de calcul pour mieux estimer la quantité de travail requise (par exemple, effectuer une meilleure analyse des fichiers à copier ou appliquer un calcul plus complexe pour mieux estimer le nombre d'étapes nécessaires pour effectuer une simulation).

D'autres fois, c'est plutôt indéterminé. Lorsque votre système installe un nouveau programme, il a souvent de nombreuses dépendances à vérifier sont installées. Et généralement, il n'a pas une idée du temps que chacun prendra et des dépendances dont ceux-ci pourraient à leur tour avoir besoin. Toutes les dépendances peuvent déjà être installées et cela peut prendre 30 secondes, ou il peut en manquer des dizaines et cela peut prendre des heures. Difficile de donner une idée juste de cela, surtout lorsque chaque situation sera unique.

De plus, d'autres drains sur le système peuvent changer au fil du temps (en raison de ce que l'utilisateur fait ... ou des processus d'arrière-plan / planifiés).

Parfois, l'estimation pourrait être améliorée si le programmeur y mettait un peu plus de travail. Mais c'est une autre réalité que ce n'est probablement pas la principale préoccupation des développeurs, par rapport à l'avancement des tâches productives réelles que l'application peut accomplir.

En fin de compte, en ce moment, je pense que c'est souvent une estimation linéaire - un aperçu du nombre de tâches de base requises que le programme a accomplies. Il s'agit donc en fait d'une estimation très approximative, et vous devriez généralement la considérer comme telle.

---

Une bonne analogie pourrait être lorsque vous lisez un livre.
Et vous décidez que vous souhaitez avoir une idée du temps qu'il faudra pour terminer le livre ...
Vous pouvez vérifier le nombre de pages et obtenir une estimation rapide en fonction du rythme jusqu'à présent.
Cela peut être une mauvaise estimation si vous venez de commencer à lire, car votre vitesse n'est peut-être pas encore typique. Mais souvent, ce serait une estimation approximative.
Ou vous pouvez également parcourir le livre, avoir une idée approximative du nombre d'images et de l'espacement du texte. Et puis avoir une meilleure idée de ce à quoi vous êtes confronté.
Mais il peut toujours s'agir d'une mauvaise estimation si, par exemple, la lisibilité du texte diminue, passant peut-être d'une prose simple à une prose complexe. Ou l'estimation peut se terminer de manière erronée car vous n'avez pas anticipé une autre tâche qui détournera votre attention.
Vous pouvez obtenir une excellente estimation en appliquant une grande partie du temps pour analyser soigneusement ce qui reste dans le livre page par page, et vous pouvez également l'améliorer en vérifiant votre calendrier et en conservant une liste des pas de lecture passés à long terme pour divers livres.
Mais en fin de compte, le temps qu'il faut pour le faire vaut-il le temps de lire le livre?

---

Nous aimerions tous de meilleurs indicateurs. Mais en l'état, nous devrons probablement nous contenter d'estimations approximatives, au moins jusqu'à ce que les ordinateurs dans leur ensemble obtiennent des algorithmes standardisés améliorés et soient capables de peser "intelligemment" et d'anticiper les facteurs dynamiques (tels que vos voies)!

Et la barre de progression est peut-être bloquée à 5% en ce moment. Il faudra juste voir comment ça se passe 8-)

J'ajouterais à la réponse de @ gnasher729 qu'il s'agit d'une autre conséquence cachée de l'indécidabilité du problème d'arrêt.

Si l'on met de côté l'imprévisibilité inhérente aux calculs interactifs, même ceux qui peuvent être isolés peuvent avoir un temps d'exécution (et un "rythme"), dont la prévisibilité ne peut être approchée par une méthode générale.

Malheureusement, une barre de progression est souvent une métaphore inutile. Quelles seraient les alternatives, vous pourriez vous demander. Si l'utilisateur est au courant de ce qui se passe "sous le capot", l'ajout de certaines informations sémantiques à l'interface peut être une option, en passant à une exécution de type trace. Sinon, créer une atmosphère calme qui réduit les attentes.

Eduquer l'utilisateur à comprendre nos limites est une troisième option à long terme.

Les barres de progression sont dessinées en fonction du nombre de sous-tâches terminées plutôt que du temps écoulé / requis pour l'achèvement.

Par exemple, supposons qu'une opération X comporte quatre sous-étapes différentes, à la fin de chaque étape, vous augmentez la barre de progression de 25%. Si une étape prenait plus de temps à exécuter, vous verriez probablement le comportement que vous avez décrit - 1 à 90% en une fois et des heures pour le reste.

La logique derrière l'utilisation du nombre de sous-tâches comme une unité plutôt que du temps est que ce dernier est imprévisible. Même dans le cas du téléchargement d'un fichier, la connexion peut chuter, par conséquent le temps ne peut pas être utilisé comme une unité. Vous préférez utiliser la quantité d'octets téléchargés et non le temps requis comme unité de progression.