Ved første tanke virker det som om å generere en nøyaktig estimering av tid, bør være ganske enkelt. Tross alt, algoritmen som produserer fremdriftslinjen, vet alle oppgavene den trenger for å gjøre det på forhånd ... riktig?

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 blir ikke opprettet likeverdige

Den enkleste måten å implementere en fremdriftslinje på er å bruke en grafisk representasjon av oppgave teller. Hvor prosentandelen er fullstendig, beregnes enkelt som Avsluttede oppgaver / Totalt antall oppgaver . Selv om dette gir en logisk følelse på første tanke, er det viktig å huske at noen oppgaver tar lengre tid å fullføre.

Vurder følgende oppgaver utført av et installasjonsprogram:

1. Opprett mappestruktur.
2. Dekomprimer og kopier 1 GB verdi av filer.
3. Opprett registeroppføringer.
4. Opprett startmenyoppføringer.

I dette eksemplet vil trinn 1, 3 og 4 fullføres veldig raskt, mens trinn 2 vil ta litt tid. Så en fremdriftslinje som arbeider med en enkel telle, vil hoppe til 25% veldig raskt, stoppe litt mens trinn 2 jobber, og hoppe deretter til 100% nesten umiddelbart.

Denne typen implementering er faktisk ganske vanlig blant fremdriftsfeltene fordi, som nevnt ovenfor, er det enkelt å implementere. Som du ser, er det imidlertid utsatt for uforholdsmessige oppgaver som skifter faktisk utviklingsprosent som det gjelder gjenstående tid.

For å omgå dette, kan noen fremdriftslinjer bruke implementeringer der trinnene vektes. Vurder trinnene ovenfor der en relativ vekt er tilordnet hvert trinn:

1. Opprett mappestruktur. [Vekt = 1]
2. Dekomprimer og kopier 1 GB verdt av filer. [Vekt = 7]
3. Opprett registeroppføringer. [Vekt = 1]
4. 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 prosessprosenten.

Tidligere resultater garanterer ikke fremtidig ytelse

Vurder et enkelt eksempel på meg og spør deg om å telle til 50 mens Jeg bruker et stoppeklokke for å klare deg. La oss si at du teller til 25 i 10 sekunder. Det ville være rimelig å anta at du vil telle de resterende tallene i ytterligere 10 sekunder, så en fremdriftssporing vil vise 50% komplett med 10 sekunder igjen.

Når tellingen din nåer 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 stille 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, det oppstår et nettverkstopp, 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 (ved hjelp av nåværende kun 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 sekundene blir husket med den nyeste verdien som erstatter den eldste (f.eks. den 61. verdien erstatter den første).
• Den effektive overføringen rate for beregningens formål er gjennomsnittet av disse målingene.
• Resterende tid beregnes som: Størrelse gjenværende / Effektiv nedlastingshastighet

Så bruk vårt scenario ovenfor (For enkelhets skyld bruker vi 1 MB = 1.000 KB):

• Ved 75 sekunder i nedlastingen, våre 60 huskete verdier vil hver være 1000 kB. Den effektive overføringshastigheten er 1000 kB (60 000 kB / 60), noe 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 ~ 992 KB (59,500 KB / 60), som gir en gjenværende tid på ~ 24,7 sekunder (24,500 KB / 992 KB).
• Ved 77 sekunder: Effektiv hastighet = ~ 983 KB (59.000 KB / 60) ~ 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 kommer her som dypp i nedlastingshastighet, blir sakte innlemmet i gjennomsnittet som brukes til å estimere gjenstående tid. Under denne metoden, hvis dypen bare varer i 10 sekunder og deretter returneres til 1 MB / s, er det ikke sannsynlig at brukeren merker forskjellen (lagre for en meget liten stall i den estimerte tiden nedtelling).

Komme til messingstenger - dette er bare en metode for å videreformidle informasjon til sluttbrukeren for den faktiske underliggende årsaken ...

Du kan ikke nøyaktig bestemme noe som er Nondeterministic

I siste instans kjender fremdriftslinjens unøyaktighet ned til det faktum at det prøver å bestemme en tid for noe som er nondeterministic. 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 en hvilken som helst 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 fremdriftslinjens bevegelse blir skizofren.

Totalt sett er det ganske enkelt at det ikke er krystallkule. Ikke en gang i seg selv vet systemet hvilken belastning det vil være under noen gang i fremtiden.

Til slutt er det egentlig ikke viktig

Målet med fremdriftslinjen er å indikere at fremgang faktisk er gjort og den respektive prosessen er ikke 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%, fullføres umiddelbart, og lar deg vente 5 minutter for de resterende ett prosent. Men hvis det respektive programmet fungerer bra generelt, bare husk at utvikleren hadde sine prioriteringer rett.

De beste gratis appene for en ny iPhone

Da jeg først kom opp med nye iPhone 5S (takket være foreldrene mine), dro jeg umiddelbart til appbutikken og begynte å laste ned apper! Å ha en smarttelefon og ikke bruke apper er som å ha en datamaskin og bare bruke den til å bla gjennom Internett. Hvis du har en iPhone, er du også heldig fordi Apple App Store er fortsatt bedre enn Android App Store, når det gjelder antall apper og kvaliteten på apper, etter min mening.Så hva e

(How-to)

Det du trenger å vite om kjøring til Uber

Kjøring for Uber virker som en ganske enkel måte å tjene litt ekstra penger på, men det er en rekke faktorer som gjør det mer komplisert enn deg kan forvente. Mange uber-drivere gjør en anstendig levetid fra å kjøre folk rundt, om de gjør det heltid eller bare deltid på toppen av hovedinntektene sine, men det er viktig å huske på at det er mer å kjøre for Uber enn bare å registrere deg, bli godkjent, hoppe i bilen og kjører folk rundt.

(how-to)