Pour l’essentiel, il est vrai que l’algorithme source sait ce qu’il doit faire à l’avance. Cependant, déterminer le temps nécessaire à chaque étape est une tâche très difficile, voire pratiquement impossible.
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:
- Créer une structure de dossier.
- Décompressez et copiez 1 Go de fichiers.
- Créer des entrées de registre.
- 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 simple décompte passerait à 25% très rapidement, resterait bloquée un peu pendant l'étape 2, puis passerait à 100% presque immédiatement.
Ce type d'implémentation est en fait assez courant parmi les barres de progression car, comme indiqué ci-dessus, il est facile à implémenter. Cependant, comme vous pouvez le constater, il est sujet à des tâches disproportionnées faussant la réel pourcentage de progression en ce qui concerne le 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:
- Créer une structure de dossier. [Poids = 1]
- Décompressez et copiez 1 Go de fichiers. [Poids = 7]
- Créer des entrées de registre. [Poids = 1]
- 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 la deuxième étape de 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
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 un peu ralenti. 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, considérons le 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 tombe à 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 et est ensuite revenu à 1 Mo / s, il est peu probable que l’utilisateur remarque la différence (à l’exception d’un blocage très mineur du compte à rebours estimé).
Accéder aux critiques - c'est simplement une méthodologie pour relayer des informations à l'utilisateur final pour la cause sous-jacente 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écutiez 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, ce 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 effectuent 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'y a 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 à des algorithmes de barre de progression car, franchement, il y a des tâches beaucoup plus importantes sur lesquelles passer du temps.
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 à attendre 5 minutes pour le 1% restant. Mais si le programme respectif fonctionne globalement bien, rappelez-vous simplement que le développeur a bien défini ses priorités.
