Waarom zijn voortgangsbalken zo onnauwkeurig?

Inhoudsopgave:

Video: Waarom zijn voortgangsbalken zo onnauwkeurig?

Video: Waarom zijn voortgangsbalken zo onnauwkeurig?
Video: Do This For Maximum Security On The Web 2024, Maart
Waarom zijn voortgangsbalken zo onnauwkeurig?
Waarom zijn voortgangsbalken zo onnauwkeurig?
Anonim
In eerste instantie lijkt het erop dat het genereren van een nauwkeurige schatting van de tijd vrij eenvoudig moet zijn. Het algoritme dat de voortgangsbalk produceert, kent immers alle taken die het van tevoren moet doen … toch?
In eerste instantie lijkt het erop dat het genereren van een nauwkeurige schatting van de tijd vrij eenvoudig moet zijn. Het algoritme dat de voortgangsbalk produceert, kent immers alle taken die het van tevoren moet doen … toch?

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 door een grafische weergave van de taakenteller te gebruiken. Waar het percentage voltooid is, wordt eenvoudigweg als berekend 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:

  1. Maak een mappenstructuur.
  2. Decomprimeer en kopieer 1 GB aan bestanden.
  3. Maak registervermeldingen.
  4. Maak start menu-items.

In dit voorbeeld zouden de stappen 1, 3 en 4 zeer snel worden voltooid, 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 vrijwel onmiddellijk naar 100% springen.

Dit type implementatie is eigenlijk vrij gebruikelijk onder voortgangsbalken omdat het, zoals hierboven vermeld, eenvoudig te implementeren is. Zoals je 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 waar stappen worden gewogen. Overweeg de bovenstaande stappen waarbij een relatief gewicht wordt toegewezen aan elke stap:

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

Met behulp van deze methode zou de voortgangsbalk bewegen in stappen van 10% (als het totale gewicht 10 is) 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 met nog 10 seconden te gaan.
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 met nog 10 seconden te gaan.

Zodra je telling echter 25 is, gooi ik tennisballen naar je. Waarschijnlijk zal dit je ritme onderbreken omdat je concentratie is verschoven van strikt getelde getallen naar ontwijkende ballen die je hebt 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 tijd stilstaat of zelfs hoger gaat.

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 heel eenvoudig om de geschatte tijd van voltooiing te bepalen. Maar 75% van de weg ernaartoe, enkele netwerkcongestie hits en je downloadsnelheid daalt naar 500 KB / s.

Afhankelijk van hoe de browser de resterende tijd berekent, kan uw ETA onmiddellijk gaan van 25 seconden tot 50 seconden (alleen met de huidige status: Resterende grootte / downloadsnelheid) of, hoogstwaarschijnlijk, de browser gebruikt een voortschrijdend gemiddeld algoritme dat zich aanpast voor fluctuaties in de 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 vorige 60 seconden wordt onthouden, waarbij de nieuwste waarde de oudste vervangt (de 61ste waarde vervangt de eerste).
  • De effectieve overdrachtssnelheid voor berekening 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 1000 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).
  • Na 77 seconden: Effectieve snelheid = ~ 983 KB (59.000 KB / 60), wat een resterende tijd van ~ 24,4 seconden oplevert (24.000 KB / 983 KB).
  • Met 78 seconden: effectieve snelheid = 975 KB (58.500 kB / 60) met een resterende resterende tijd van ~ 24,1 seconden (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. Onder 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 in de geschatte tijdaftelprocedure).

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 aanvraag 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 serverbronnen, in het bijzonder voor de database, verzoeken verwerken voor zowel uw upgrade als de door de gebruiker gestarte query - 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 zou afbreuk doen aan de prestatie. Of een geplande taak kan beginnen die een geheugenintensief proces uitvoert. Je snapt het idee.

Als, misschien, een meer realistisch exemplaar voor een dagelijkse gebruiker - overweeg om Windows Update of een virusscan uit te voeren. Bij beide bewerkingen worden op de achtergrond resource-intensieve bewerkingen uitgevoerd. 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 aan door te spenderen.

Natuurlijk heb je het volste recht geïrriteerd te zijn wanneer een voortgangsbalk meteen naar 99% springt en je vervolgens 5 minuten laat wachten 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 gezet.

Aanbevolen: