Waarom zijn voortgangsbalken zo onnauwkeurig?

In eerste instantie lijkt het erop dat het genereren van een nauwkeurige schatting van de tijd redelijk gemakkelijk zou moeten zijn. Het algoritme dat de voortgangsbalk produceert, weet immers alle taken die het moet doen van tevoren ... juist?

Voor het grootste deel is het waar dat het bronalgoritme wel weet wat het moet doen van tevoren. Het vastzetten van de tijd die nodig is om elke stap uit te voeren, is echter een zeer moeilijke, zo niet vrijwel onmogelijk, taak.

Alle taken zijn niet gelijk gemaakt

De eenvoudigste manier om een voortgangsbalk te implementeren, is om een grafische weergave van de taakenteller te gebruiken. Waar het percentage voltooid is, wordt eenvoudigweg berekend als Voltooide taken / totaal aantal taken. Hoewel dit logisch gezien bij het eerst nadenken, is het belangrijk om te onthouden dat (uiteraard) sommige taken langer duren om te voltooien.

Overweeg de volgende taken die door een installatieprogramma worden uitgevoerd:

Maak mappenstructuur.
Decomprimeer en kopieer 1 GB aan bestanden.
Maak registervermeldingen.
Maak start menu-items.

In dit voorbeeld zouden stappen 1, 3 en 4 zeer snel voltooien, terwijl stap 2 enige tijd zou duren. Dus een voortgangsbalk die werkt aan een eenvoudige telling zou snel naar 25% springen, een tijdje stil blijven staan terwijl stap 2 werkt en dan meteen naar 100% springen..

Dit soort implementatie is eigenlijk vrij gebruikelijk onder voortgangsbalken omdat het, zoals hierboven vermeld, eenvoudig te implementeren is. Zoals u ziet, is het echter onderhevig aan onevenredige taken die de werkelijk voortgangspercentage omdat het betrekking heeft op de resterende tijd.

Om dit te omzeilen, kunnen sommige voortgangsbalken implementaties gebruiken waarbij stappen worden gewogen. Overweeg de bovenstaande stappen waarbij een relatief gewicht wordt toegewezen aan elke stap:

Maak mappenstructuur. [Gewicht = 1]
Decomprimeer en kopieer 1 GB aan bestanden. [Gewicht = 7]
Maak registervermeldingen. [Gewicht = 1]
Maak start menu-items. [Gewicht = 1]

Met behulp van deze methode zou de voortgangsbalk in stappen van 10% (als het totale gewicht is 10) bewegen met stappen 1, 3 en 4, waarbij de balk 10% wordt verplaatst bij voltooiing en stap 2 70% wordt verplaatst. Hoewel zeker niet perfect, zijn methoden zoals deze een eenvoudige manier om een beetje meer nauwkeurigheid toe te voegen aan het percentage van de voortgangsbalk.

Resultaten uit het verleden garanderen geen toekomstige prestaties

Overweeg een eenvoudig voorbeeld van me dat je vraagt om tot 50 te tellen terwijl ik een stopwatch gebruik om je te timen. Laten we zeggen dat je tot 25 in 10 seconden telt. Het zou redelijk zijn om aan te nemen dat je de resterende getallen in nog eens 10 seconden zult tellen, dus een voortgangsbalk die dit zou volgen zou 50% compleet zijn en 10 seconden resterend.

Zodra je telling echter 25 is, gooi ik tennisballen naar je. Waarschijnlijk zal dit je ritme breken omdat je concentratie is verschoven van het strikt tellen van getallen naar ballen die je weg zijn gegooid. Ervan uitgaande dat je door kunt gaan met tellen, is je tempo zeker een beetje vertraagd. Dus nu is de voortgangsbalk nog steeds in beweging, maar in een veel langzamer tempo waarbij de geschatte resterende tijd stilstaat of zelfs hoger stijgt.

Bekijk een bestand download voor een meer praktisch voorbeeld hiervan. U downloadt momenteel een bestand van 100 MB tegen een snelheid van 1 MB / s. Dit is zeer eenvoudig om de geschatte tijd van voltooiing te bepalen. Maar 75% van de weg ernaartoe, enkele netwerkcongestie hits en je downloadsnelheid zakt naar 500 KB / s.

Afhankelijk van hoe de browser de resterende tijd berekent, kan uw ETA onmiddellijk van 25 seconden tot 50 seconden gaan (alleen met de huidige status: Resterende grootte / downloadsnelheid) of, hoogstwaarschijnlijk, de browser gebruikt een voortschrijdend gemiddeld algoritme dat zich aanpast voor fluctuaties in overdrachtssnelheid zonder dramatische sprongen naar de gebruiker te tonen.

Een voorbeeld van een rolling algoritme met betrekking tot het downloaden van een bestand kan ongeveer zo werken:

De overdrachtssnelheid van de afgelopen 60 seconden wordt onthouden, waarbij de nieuwste waarde de oudste vervangt (de 61e waarde vervangt de eerste).
De effectieve overdrachtssnelheid voor het berekenen is het gemiddelde van deze metingen.
Resterende tijd wordt berekend als: Resterende grootte / effectieve downloadsnelheid

Dus gebruikmakend van ons scenario hierboven (omwille van de eenvoud, gebruiken we 1 MB = 1.000 KB):

Na 75 seconden in de download zouden onze 60 onthouden waarden elk 1.000 KB zijn. De effectieve overdrachtssnelheid is 1.000 KB (60.000 KB / 60), wat een resterende tijd van 25 seconden oplevert (25.000 KB / 1.000 KB).
Na 76 seconden (waarbij de overdrachtssnelheid daalt tot 500 KB), wordt de effectieve downloadsnelheid ~ 992 KB (59.500 KB / 60), wat een resterende tijd van ~ 24,7 seconden oplevert (24.500 KB / 992 KB).
Met 77 seconden: effectieve snelheid = ~ 983 kB (59.000 KB / 60) met een resterende resterende tijd van ~ 24,4 seconden (24.000 KB / 983 kB).
Met 78 seconden: effectieve snelheid = 975 KB (58.500 kB / 60) levert nog een resterende tijd van ~ 24,1 seconden op (23.500 KB / 975 KB).

Je kunt het patroon hier zien ontstaan, omdat de daling van de downloadsnelheid langzaam wordt opgenomen in het gemiddelde dat wordt gebruikt om de resterende tijd te schatten. Bij deze methode, als de dip slechts 10 seconden heeft geduurd en vervolgens is teruggekeerd naar 1 MB / s, is het onwaarschijnlijk dat de gebruiker het verschil opmerkt (met uitzondering van een zeer kleine stal bij het aftellen van de geschatte tijd).

Krijgen van de koperen tacks - dit is gewoon een methodiek voor het doorgeven van informatie aan de eindgebruiker voor de werkelijke onderliggende oorzaak ...

Je kunt niet nauwkeurig bepalen wat niet-deterministisch is

Uiteindelijk komt de onnauwkeurigheid van de voortgangsbalk neer op het feit dat het probeert een tijd te bepalen voor iets dat niet-deterministisch is. Omdat computers taken zowel op verzoek als op de achtergrond verwerken, is het bijna onmogelijk om te weten welke systeembronnen er op enig moment in de toekomst beschikbaar zullen zijn - en het is de beschikbaarheid van systeembronnen die nodig is om een taak te voltooien.

Gebruik een ander voorbeeld, stel dat u een programma-upgrade uitvoert op een server die een vrij intensieve database-update uitvoert. Tijdens dit updateproces stuurt een gebruiker een veeleisend verzoek naar een andere database die op dit systeem wordt uitgevoerd. Nu moeten de serverresources, met name voor de database, aanvragen voor zowel uw upgrade als de door de gebruiker gestarte query verwerken - een scenario dat zeker de uitvoeringstijd nadelig zal beïnvloeden. Als alternatief zou een gebruiker een groot bestandoverdrachtverzoek kunnen initiëren dat de opslagdoorvoer zou belasten, hetgeen eveneens afbreuk zou doen aan de prestatie. Of een geplande taak kan starten die een geheugenintensief proces uitvoert. Je snapt het idee.

Als, misschien, een realistischer voorbeeld voor een dagelijkse gebruiker - overweeg om Windows Update of een virusscan uit te voeren. Beide bewerkingen voeren op de achtergrond intensieve bewerkingen uit. Dientengevolge is de voortgang die elk maakt afhankelijk van wat de gebruiker op dat moment doet. Als u uw e-mail leest terwijl deze wordt uitgevoerd, zal de vraag naar systeembronnen waarschijnlijk laag zijn en zal de voortgangsbalk consistent worden verplaatst. Aan de andere kant, als u bezig bent met grafische bewerking, zal uw vraag naar systeembronnen veel groter zijn, waardoor de beweging van de voortgangsbalk schizofreen wordt.

Over het algemeen is het eenvoudig dat er geen kristallen bol is. Zelfs het systeem zelf weet niet welke belasting het op enig moment in de toekomst zal ondergaan.

Uiteindelijk doet het er echt niet toe

De bedoeling van de voortgangsbalk is om, nou ja, aan te geven dat er inderdaad vooruitgang wordt geboekt en dat het respectieve proces niet wordt opgehangen. Het is leuk als de voortgangsindicator klopt, maar meestal is het slechts een kleine ergernis als dat niet zo is. Voor het grootste deel zullen ontwikkelaars niet veel tijd en moeite steken in algoritmen voor voortgangsbalks, omdat er eerlijk gezegd veel belangrijker taken zijn om tijd te besteden aan.

Natuurlijk heb je het volste recht geïrriteerd te zijn als een voortgangsbalk meteen 99% voltooit en je vervolgens 5 minuten wacht op de resterende één procent. Maar als het betreffende programma over het algemeen goed werkt, herinner jezelf er dan aan dat de ontwikkelaar zijn prioriteiten op een rijtje had.