Pourquoi les barres de progression sont-elles si inexactes?

À première vue, il semble que générer une estimation précise du temps devrait être assez facile. Après tout, l’algorithme produisant la barre de progression connaît toutes les tâches qu’il doit effectuer à l’avance… juste?

Pour l’essentiel, il est vrai que l’algorithme source sait ce qu’il doit faire à l’avance. Cependant, il est très difficile, voire pratiquement impossible, de déterminer le temps nécessaire à chaque étape..

Toutes les tâches ne sont pas créées égales

Le moyen le plus simple d'implémenter une barre de progression consiste à utiliser une représentation graphique du compteur de tâches. Où le pourcentage achevé est simplement calculé comme Tâches complétées / Nombre total de tâches. Bien que cela semble logique à première vue, il est important de se rappeler que certaines tâches prennent (évidemment) plus longtemps..

Prenez en compte les tâches suivantes effectuées par un programme d'installation:

1. Créer une structure de dossier.
2. Décompressez et copiez 1 Go de fichiers.
3. Créer des entrées de registre.
4. Créer des entrées de menu de démarrage.

Dans cet exemple, les étapes 1, 3 et 4 s’achèveraient très rapidement, tandis que l’étape 2 prendrait un certain temps. Ainsi, une barre de progression fonctionnant sur un comptage simple passerait à 25% très rapidement, resterait bloquée un peu pendant que l'étape 2 fonctionnerait, puis passerait à 100% presque immédiatement.

Ce type de mise en œuvre est en fait assez courant parmi les barres de progression car, comme indiqué ci-dessus, il est facile à mettre en œuvre. Cependant, comme vous pouvez le constater, il est sujet à des tâches disproportionnées faussant la réel pourcentage de progression par rapport au temps restant.

Pour contourner ce problème, certaines barres de progression peuvent utiliser des implémentations dans lesquelles les étapes sont pondérées. Considérez les étapes ci-dessus où un poids relatif est attribué à chaque étape:

1. Créer une structure de dossier. [Poids = 1]
2. Décompressez et copiez 1 Go de fichiers. [Poids = 7]
3. Créer des entrées de registre. [Poids = 1]
4. Créer des entrées de menu de démarrage. [Poids = 1]

En utilisant cette méthode, la barre de progression se déplacerait par incréments de 10% (le poids total étant de 10), les étapes 1, 3 et 4 déplaçant la barre de 10% à la fin et l'étape 2 la déplaçant à 70%. Bien que ces méthodes ne soient certainement pas parfaites, elles constituent un moyen simple d’ajouter un peu plus de précision au pourcentage de barre de progression..

Les résultats passés ne garantissent pas les performances futures

Prenons un exemple simple de moi vous demandant de compter jusqu’à 50 alors que j’utilise un chronomètre pour chronométrer. Disons que vous comptez jusqu'à 25 en 10 secondes. Il serait raisonnable de supposer que vous compterez les nombres restants dans 10 secondes supplémentaires. Par conséquent, une barre de progression indiquant le temps écoulé indique 50% de fin et 10 secondes restantes..

Une fois que votre compte atteint 25, cependant, je commence à vous lancer des balles de tennis. Cela va probablement briser votre rythme, car votre concentration est passée du simple comptage de nombres à l’esquive des balles. En supposant que vous puissiez continuer à compter, votre rythme a certainement ralenti un peu. Alors maintenant, la barre de progression est toujours en mouvement, mais à un rythme beaucoup plus lent, avec le temps estimé qui reste soit à l'arrêt, soit en train de monter..

Pour un exemple plus pratique, envisagez un téléchargement de fichier. Vous téléchargez actuellement un fichier de 100 Mo à un débit de 1 Mo / s. Il est très facile de déterminer le délai d’achèvement estimé. Mais 75% du trajet est là, une congestion du réseau est atteinte et votre taux de téléchargement chute à 500 Ko / s..

En fonction de la manière dont le navigateur calcule le temps restant, votre ETA peut instantanément passer de 25 à 50 secondes (en utilisant l'état actuel uniquement: Taille restante / Vitesse de téléchargement) ou, très probablement, le navigateur utilise un algorithme de moyenne mobile qui tient compte des fluctuations de la vitesse de transfert sans afficher de sauts dramatiques pour l'utilisateur.

Un exemple d'algorithme glissant en ce qui concerne le téléchargement d'un fichier pourrait fonctionner comme ceci:

• La vitesse de transfert des 60 dernières secondes est mémorisée, la valeur la plus récente remplaçant la plus ancienne (par exemple, la 61ème valeur remplace la première)..
• Le taux de transfert effectif aux fins du calcul est la moyenne de ces mesures.
• Le temps restant est calculé comme suit: Taille restante / Vitesse de téléchargement effective

Donc, en utilisant notre scénario ci-dessus (par souci de simplicité, nous utiliserons 1 Mo = 1 000 Ko):

• Après 75 secondes de téléchargement, nos 60 valeurs mémorisées sont chacune de 1 000 Ko. Le taux de transfert effectif est de 1 000 Ko (60 000 Ko / 60), ce qui laisse un temps restant de 25 secondes (25 000 Ko / 1 000 Ko)..
• À 76 secondes (où la vitesse de transfert descend à 500 Ko), la vitesse de téléchargement effective devient ~ 992 Ko (59 500 Ko / 60), ce qui laisse un temps restant d'environ 24,7 secondes (24 500 Ko / 992 Ko)..
• À 77 secondes: vitesse effective = ~ 983 Ko (59 000 Ko / 60), ce qui donne un temps restant d'environ 24,4 secondes (24 000 Ko / 983 Ko)..
• À 78 secondes: vitesse effective = 975 Ko (58 500 Ko / 60), ce qui donne un temps restant d'environ 24,1 secondes (23 500 Ko / 975 Ko)..

Vous pouvez voir le schéma qui se dégage ici lorsque la baisse de la vitesse de téléchargement est lentement incorporée à la moyenne utilisée pour estimer le temps restant. Selon cette méthode, si le creux n’a duré que 10 secondes, puis est revenu à 1 Mo / s, il est peu probable que la différence soit remarquée (sauf pour un décrochage très mineur dans le compte à rebours estimé)..

Accéder aux critiques - il s’agit simplement d’une méthodologie permettant de relayer les informations vers l’utilisateur final pour déterminer la cause réelle…

Vous ne pouvez pas déterminer avec précision quelque chose de non déterministe

En fin de compte, l’imprécision de la barre de progression se résume au fait qu’elle tente de déterminer le moment pour quelque chose de non déterministe. Étant donné que les ordinateurs traitent des tâches à la demande et en arrière-plan, il est presque impossible de savoir quelles ressources système seront disponibles à l'avenir - et c'est la disponibilité des ressources système qui est nécessaire à l'exécution de toute tâche..

En utilisant un autre exemple, supposons que vous exécutez une mise à niveau du programme sur un serveur qui effectue une mise à jour de la base de données assez intensive. Pendant ce processus de mise à jour, un utilisateur envoie ensuite une requête exigeante à une autre base de données s'exécutant sur ce système. Désormais, les ressources du serveur, en particulier pour la base de données, doivent traiter les requêtes pour votre mise à niveau ainsi que la requête initiée par l'utilisateur - un scénario qui sera certainement préjudiciable au temps d'exécution. Alternativement, un utilisateur pourrait initier une demande de transfert de fichier volumineux, ce qui imposerait une charge du débit de stockage qui nuirait également aux performances. Ou bien une tâche planifiée peut démarrer, ce qui exécute un processus gourmand en mémoire. Vous avez eu l'idée.

En tant qu’instance plus réaliste pour un utilisateur ordinaire, envisagez d’exécuter Windows Update ou une analyse antivirus. Ces deux opérations exécutent des opérations gourmandes en ressources en arrière-plan. En conséquence, la progression de chacun dépend de ce que l'utilisateur fait à ce moment-là. Si vous lisez votre courrier électronique pendant son exécution, il est probable que la demande en ressources système sera faible et que la barre de progression sera constamment déplacée. D'autre part, si vous modifiez des graphiques, votre demande en ressources système sera beaucoup plus importante, ce qui entraînera une schizophrénie du mouvement de la barre de progression..

Dans l’ensemble, c’est simplement qu’il n’ya pas de boule de cristal. Même le système lui-même ne sait pas quelle charge il subira à l'avenir..

En fin de compte, cela ne compte vraiment pas

L’objectif de la barre de progression est de bien indiquer que des progrès sont effectivement accomplis et que le processus correspondant n’est pas bloqué. C’est bien quand l’indicateur de progression est précis, mais c’est généralement un désagrément mineur quand ce n’est pas le cas. Pour la plupart, les développeurs ne vont pas consacrer beaucoup de temps et d’efforts à l’algorithme de la barre de progression car, franchement, il ya beaucoup plus de tâches importantes à prendre en compte..

Bien sûr, vous avez tout à fait le droit d’être ennuyé quand une barre de progression passe à 99% d’être complétée instantanément et vous oblige ensuite à attendre 5 minutes pour le 1% restant. Mais si le programme respectif fonctionne globalement bien, rappelez-vous simplement que le développeur avait ses priorités.