Bij het eerste idee 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?

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

Alle taken worden niet gelijk gemaakt

De eenvoudigste manier om een ​​voortgangsbalk te implementeren, is door een grafische weergave te gebruiken. weergave van taakteller. Waar het percentage voltooid is, wordt eenvoudig berekend als Voltooide taken / Totaal aantal taken . Hoewel dit logisch gezien het eerste idee is, is het belangrijk om te onthouden dat (uiteraard) sommige taken langer duren om te voltooien.

Overweeg de volgende taken uit te voeren door een installatieprogramma:

1. Maak een mappenstructuur.
2. Decomprimeren en kopiëren 1 GB aan bestanden.
3. Maak registervermeldingen.
4. Maak startmenu-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 onmiddellijk naar 100% springen.

Dit type implementatie is eigenlijk vrij gebruikelijk onder voortgangsbalken omdat, zoals hierboven vermeld, het eenvoudig te implementeren is. Zoals u ziet, is het echter onderhevig aan onevenredige taken die het werkelijke voortgangspercentage scheeftrekken als het betrekking heeft op 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:

1. Maak een mapstructuur. [Gewicht = 1]
2. Decomprimeer en kopieer 1 GB aan bestanden. [Gewicht = 7]
3. Registervermeldingen maken. [Gewicht = 1]
4. Maak startmenu-items. [Gewicht = 1]

Met deze methode beweegt de voortgangsbalk 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 wordt verplaatst 70%. Hoewel dit zeker niet perfect is, zijn methoden zoals deze een eenvoudige manier om een ​​beetje meer nauwkeurigheid toe te voegen aan het voortgangsbalkpercentage.

Resultaten uit het verleden garanderen geen toekomstige prestaties

Overweeg een eenvoudig voorbeeld van mijn vraag om tot 50 te tellen terwijl Ik gebruik een stopwatch 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 nummers in nog eens 10 seconden zult tellen, dus een voortgangsbalk die dit bijhoudt zou 50% compleet zijn en 10 seconden resteren.

Zodra je telling 25 wordt, begin ik met het gooien van tennisballen bij 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.

Overweeg een bestanddownload 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 treft en uw 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 (met behulp van huidige alleen 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 vorige 60 seconden wordt onthouden met de nieuwste waarde die de oudste waarde vervangt (bijv. de 61ste waarde vervangt de eerste).
• De effectieve overdracht snelheid voor het doel van berekening is het gemiddelde van deze metingen.
• Resterende tijd wordt berekend als: Grootte resterend / effectief Downloadsnelheid

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

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

U kunt zien het patroon dat hier opduikt, aangezien 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 (behalve voor een heel kleine stal in de geschatte afteltijd).

Naar de koperen tacks gaan - dit is simpelweg een methodiek voor het doorgeven van informatie aan de eindgebruiker voor de feitelijke onderliggende oorzaak ...

U kunt niet nauwkeurig bepalen wat niet-deterministisch is

Uiteindelijk komt de onnauwkeurigheid van de voortgangsbalk neer op het feit dat het probeert een tijd 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.

Veronderstel 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. U krijgt het idee.

Misschien een realistischer voorbeeld 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 je bezig bent met grafische bewerking, dan zal je 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 wel aan te geven dat er inderdaad vooruitgang wordt geboekt en het respectieve proces is niet 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 de algoritmen van de voortgangsbalk, omdat er eerlijk gezegd veel belangrijker taken zijn om tijd aan te besteden.

Natuurlijk heb je het volste recht geïrriteerd te zijn wanneer een voortgangsbalk onmiddellijk naar 99% springt en u vervolgens 5 minuten wacht voor de resterende één procent. Maar als het betreffende programma over het algemeen goed werkt, moet u er alleen aan denken dat de ontwikkelaar zijn prioriteiten recht had.

Leeg de prullenmand in OS X snel met Terminal

Om de een of andere reden is het legen van de prullenbak in OS X altijd een langzaam proces geweest, vooral als je daar veel bestanden hebt. Ik tankte een enorme map met meer dan 10.000 items erin en het duurde maar liefst 30 minuten om het te vernietigen!Je kunt hier niet teveel aan doen, want het is zoals het besturingssysteem werkt, maar als je Terminal kunt gebruiken en niet bang bent, kun je het proces versnellen

(How-to)

Software om automatisch apparaatstuurprogramma's voor pc's te back-uppen of te updaten

Een apparaatstuurprogramma is een stukje software waarmee het besturingssysteem (Windows XP, Windows 7, enzovoort) wordt verteld hoe met een stuk hardware moet worden gecommuniceerd. Windows 7 kan bijvoorbeeld op verschillende hardware worden geïnstalleerd, afhankelijk van het feit of de computer is gemaakt door HP, Dell, Sony, enzovoort, zodat Windows, om met al die verschillende hardware te werken, een stukje software van de fabrikant nodig heeft die het OS vertelt hoe te communiceren met het apparaat.

(How-to)