For det meste er det sant at kildealgoritmen vet hva den trenger for å gjøre det på forhånd. Det er imidlertid en svært vanskelig, om ikke praktisk talt umulig oppgave å knytte ned tiden det tar for å utføre hvert trinn.
Alle oppgaver er ikke opprettet likeverdige
Den enkleste måten å implementere en fremdriftslinje på er å bruke en grafisk representasjon av oppgavetelleren. Hvor prosenten fullført er bare beregnet som Fullførte oppgaver / Totalt antall oppgaver. Selv om dette gir en logisk følelse på første tanke, er det viktig å huske at (åpenbart) noen oppgaver tar lengre tid å fullføre.
Vurder følgende oppgaver utført av en installatør:
- Opprett mappestruktur.
- Dekomprimer og kopier 1 GB verdi av filer.
- Opprett registeroppføringer.
- Opprett startmenyoppføringer.
I dette eksemplet vil trinn 1, 3 og 4 fullføre veldig raskt mens trinn 2 vil ta litt tid. Så en fremdriftslinje som arbeider med en enkel telle, vil hoppe til 25% veldig raskt, stanse litt mens trinn 2 jobber, og hoppe deretter til 100% nesten umiddelbart.
Denne type implementering er faktisk ganske vanlig blant fremdriftsstenger fordi, som nevnt ovenfor, er det enkelt å implementere. Men som du kan se, er det gjenstand for uforholdsmessige oppgaver som skaper faktiske Progresentasjonsprosent som det gjelder gjenstående tid.
For å omgå dette kan enkelte fremdriftsfelt bruke implementeringer der trinnene vektes. Vurder trinnene ovenfor der en relativ vekt er tilordnet hvert trinn:
- Opprett mappestruktur. [Vekt = 1]
- Dekomprimer og kopier 1 GB verdi av filer. [Vekt = 7]
- Opprett registeroppføringer. [Vekt = 1]
- Opprett startmenyoppføringer. [Vekt = 1]
Ved hjelp av denne metoden vil fremdriftslinjen bevege seg i trinn på 10% (da totalvekten er 10) med trinn 1, 3 og 4 flytter stangen 10% etter ferdigstillelse og trinn 2 beveger den 70%. Selv om det ikke er helt perfekt, er metoder som dette en enkel måte å legge til litt mer nøyaktighet i prosesslinjen prosentvis.
Tidligere resultater garanterer ikke fremtidig ytelse
Når tellingen din nå 25, begynner jeg å kaste tennisballer på deg. Sannsynligvis vil dette ødelegge din rytme ettersom konsentrasjonen din har flyttet fra strengt telle tall til å dodging baller kastet deg. Forutsatt at du er i stand til å fortsette å telle, har tempoet din sikkert redusert litt. Så nå går fremdriftslinjen fortsatt, men i et mye langsommere tempo med den estimerte tiden som gjenstår, enten ved stillstand eller faktisk klatring høyere.
For et mer praktisk eksempel på dette, bør du vurdere en filnedlasting. Du laster ned for øyeblikket en 100 MB-fil med en hastighet på 1 MB / s. Dette er veldig enkelt å bestemme estimert sluttidspunkt. Men 75% av veien der, noen nettverksbelastning treffer og nedlastingsraten din faller til 500 kB / s.
Avhengig av hvordan nettleseren beregner gjenværende tid, kan ETA øyeblikkelig gå fra 25 sekunder til 50 sekunder (kun ved bruk av nåværende tilstand: Størrelse gjenværende / Nedlastingshastighet) eller, mest sannsynlig, bruker nettleseren en rullende gjennomsnittsalgoritme som ville justere for svingninger i overføringshastighet uten å vise dramatiske hopp til brukeren.
Et eksempel på en rullende algoritme med hensyn til å laste ned en fil kan virke noe slikt:
- Overføringshastigheten for de forrige 60 sekunder blir husket med den nyeste verdien som erstatter den eldste (for eksempel den 61. verdien erstatter den første).
- Den effektive overføringshastigheten for beregningsgrunnlaget er gjennomsnittet av disse målingene.
- Resterende tid beregnes som: Størrelse gjenværende / Effektiv nedlastingshastighet
Så bruker vi vårt scenario ovenfor (for enkelhets skyld vil vi bruke 1 MB = 1000 KB):
- På 75 sekunder i nedlastingen vil våre 60 huskete verdier hver være 1000 KB. Den effektive overføringshastigheten er 1000 kB (60 000 kB / 60), som gir en gjenværende tid på 25 sekunder (25 000 kB / 1000 kB).
- På 76 sekunder (hvor overføringshastigheten faller til 500 KB), blir den effektive nedlastingshastigheten ~ 992 KB (59 500 KB / 60), som gir en gjenværende tid på ~ 24,7 sekunder (24 500 KB / 992 KB).
- På 77 sekunder: Effektiv hastighet = ~ 983 KB (59 000 kB / 60), som gir gjenværende tid på ~ 24,4 sekunder (24 000 kB / 983 kB).
- På 78 sekunder: Effektiv hastighet = 975 KB (58 500 KB / 60), som gir gjenværende tid på ~ 24,1 sekunder (23,500 KB / 975 KB).
Du kan se mønsteret som dukker opp her, da dukkert i nedlastingshastighet er sakte innlemmet i gjennomsnittet som brukes til å estimere gjenstående tid. Under denne metoden, hvis dukkert bare varer i 10 sekunder og deretter returneres til 1 MB / s, er det ikke sannsynlig at brukeren merker forskjellen (lagre for en svært liten båt i estimert nedtelling av tid).
Å komme til messingstenger - dette er ganske enkelt metodikk for videreformidling av informasjon til sluttbrukeren for den faktiske underliggende årsaken …
Du kan ikke nøyaktig bestemme noe som er ubestemt
I siste instans kjener fremdriftslinjens unøyaktighet ned til det faktum at det prøver å bestemme en tid for noe som er nondeterministisk. Fordi datamaskiner behandler oppgaver både på etterspørsel og i bakgrunnen, er det nesten umulig å vite hvilke systemressurser som vil være tilgjengelige på et hvilket som helst tidspunkt i fremtiden - og det er tilgjengeligheten av systemressurser som er nødvendig for enhver oppgave å fullføre.
Bruk et annet eksempel, anta at du kjører en programoppgradering på en server som utfører en ganske intensiv databaseoppdatering. Under denne oppdateringsprosessen sender en bruker en krevende forespørsel til en annen database som kjører på dette systemet. Nå må serverressursene, spesielt for databasen, behandle forespørsler både for oppgraderingen din og for brukerens initierte spørring - et scenario som sikkert vil være gjensidig skadelig for kjøretiden. Alternativt kan en bruker initiere en stor filoverføringsforespørsel som vil beskatte lagringsmengden som vil forringe ytelsen også. Eller en planlagt oppgave kan sparke som utfører en minneintensiv prosess. Du får ideen.
Som kanskje et mer realistisk eksempel for en daglig bruker - vurdere å kjøre Windows Update eller en virusskanning. Begge disse operasjonene utfører ressursintensive operasjoner i bakgrunnen. Som et resultat av dette, er fremdriften som hver produserer, avhengig av hva brukeren gjør på det tidspunktet. Hvis du leser e-posten din mens dette kjører, vil sannsynligheten for systemressurser være lav og fremdriftslinjen vil bevege seg konsistent. På den annen side, hvis du gjør grafikkredigering, vil etterspørselen din på systemressurser bli mye større, noe som vil føre til at fremdriftslinjebevegelsen blir skizofren.
Samlet sett er det ganske enkelt at det ikke er krystallkule. Ikke engang systemet vet selv hvilken belastning den vil være under noen steder i fremtiden.
Til syvende og sist betyr det egentlig ikke noe
Hensikten med fremdriftslinjen er å godt indikere at fremgang faktisk er gjort og den respektive prosessen ikke er hengt. Det er fint når fremdriftsindikatoren er nøyaktig, men vanligvis er det bare en liten irritasjon når det ikke er det. For det meste vil utviklere ikke bruke mye tid og krefter på fremdriftslinjalgoritmer fordi det er oppriktig mye viktigere oppgaver å bruke tid på.
Selvfølgelig har du all rett til å bli irritert når en fremdriftslinje hopper til 99% fullstendig umiddelbart, og lar deg vente 5 minutter for de resterende 1 prosent. Men hvis det respektive programmet fungerer bra generelt, bare minn deg selv at utvikleren hadde sine prioriteringer rett.
