Zakaj so napovedi napredka tako netočne?

Na prvi pogled se zdi, da bi bilo treba ustvariti natančno oceno časa precej enostavno. Konec koncev, algoritem, ki proizvaja vrstico napredka, ve vse naloge, ki jih mora opraviti pred časom… prav?

Večinoma je res, da izvorni algoritem ve, kaj mora storiti pred časom. Vendar je določitev časa, ki bo potreben za izvedbo vsakega koraka, zelo težka, če ne skoraj nemogoča naloga.

Vse naloge niso enake

Najenostavnejši način izvajanja vrstice napredka je uporaba grafičnega prikaza števca opravil. Kjer je odstotek popoln, se preprosto izračuna kot Dokončana opravila / Skupno število nalog. Čeprav je to na prvi pogled logičen smisel, je pomembno, da se spomnimo, da (seveda) nekaj nalog traja dlje.

Upoštevajte naslednje naloge, ki jih izvaja namestitveni program:

1. Ustvarite strukturo map.
2. Razpakirajte in kopirajte datoteke v vrednosti 1 GB.
3. Ustvarite vnose v register.
4. Ustvarite vnose začetnega menija.

V tem primeru bi se koraki 1, 3 in 4 končali zelo hitro, medtem ko bi korak 2 trajal nekaj časa. Vrstica napredovanja, ki deluje na preprostem štetju, bi zelo hitro skočila na 25%, zaustavila se bo nekaj časa, medtem ko bo korak 2 deloval, in nato skočil na 100% skoraj takoj.

Ta vrsta izvajanja je dejansko precej pogosta med vrsticami napredka, ker je, kot je navedeno zgoraj, enostavna za izvajanje. Vendar, kot lahko vidite, je podvržena nesorazmernim nalogam, ki izkrivljajo dejansko odstotek napredka, ki se nanaša na preostali čas.

Če se želite izogniti temu, lahko nekatere vrstice napredka uporabljajo izvedbe, kjer so koraki uteženi. Upoštevajte zgornje korake, kjer je vsakemu koraku dodeljena relativna teža:

1. Ustvarite strukturo map. [Teža = 1]
2. Razpakirajte in kopirajte datoteke v vrednosti 1 GB. [Teža = 7]
3. Ustvarite vnose v register. [Teža = 1]
4. Ustvarite vnose začetnega menija. [Teža = 1]

S to metodo se bo vrstica napredovanja gibala v korakih po 10% (saj je skupna teža 10) s koraki 1, 3 in 4, ki premikajo bar 10% ob zaključku in korak 2 premakne 70%. Čeprav zagotovo ni popoln, so metode, kot je ta, preprost način za dodajanje malo več natančnosti odstotku napredka.

Pretekli rezultati ne zagotavljajo uspešnosti v prihodnosti

Razmislite o preprostem primeru, da vas prosim, da štetje do 50, medtem ko uporabljam štoparico, da vam čas. Recimo, da štejete do 25 v 10 sekundah. Smiselno je domnevati, da boste preostale številke prešteli v dodatnih 10 sekundah, tako da bo sledenje vrstici napredka pokazalo 50% dokončanja z 10 sekundami.

Ko štetje doseže 25, pa začnem metati teniške žogice na vas. Verjetno bo to prekinilo vaš ritem, saj se je vaša koncentracija premaknila od strogo štetja številk do izogibanja žogicam, ki so vam vrgli pot. Ob predpostavki, da lahko nadaljujete s štetjem, se je vaš ritem nekoliko upočasnil. Torej je napredek še vedno v gibanju, vendar z veliko počasnejšo hitrostjo, ko je predvideni čas bodisi v mirovanju bodisi dejansko višji..

Za bolj praktičen primer tega razmislite o prenosu datoteke. Trenutno prenesete 100 MB datoteko s hitrostjo 1 MB / s. To je zelo enostavno določiti ocenjeni čas dokončanja. Toda 75% poti tam, nekateri zadetki omrežja in hitrost prenosa pade na 500 KB / s.

Odvisno od tega, kako brskalnik izračunava preostali čas, se lahko vaša ETA takoj premakne od 25 sekund do 50 sekund (z uporabo trenutnega stanja samo: Velikost Preostala / Hitrost prenosa) ali najverjetneje brskalnik uporablja algoritem, ki bi se prilagodil za nihanja hitrosti prenosa brez prikazovanja dramatičnih skokov uporabniku.

Primer algoritma za prestavljanje v zvezi s prenosom datoteke lahko deluje tako:

• Hitrost prenosa za zadnjih 60 sekund se spomni z najnovejšo vrednostjo, ki nadomešča najstarejšo (npr. 61. vrednost nadomesti prvo).
• Dejanska stopnja prenosa za namen izračuna je povprečje teh meritev.
• Preostali čas se izračuna kot: Velikost preostale / učinkovita hitrost prenosa

Torej z uporabo zgornjega scenarija (zaradi enostavnosti bomo uporabili 1 MB = 1.000 KB):

• Pri 75 sekundah prenosa bo vsakih 60 spominjanih vrednosti 1000 KB. Dejanska hitrost prenosa je 1.000 KB (60.000 KB / 60), kar pomeni, da je preostali čas 25 sekund (25.000 KB / 1.000 KB).
• Pri 76 sekundah (kjer hitrost prenosa pade na 500 KB) postane dejanska hitrost prenosa ~ 992 KB (59,500 KB / 60), kar daje preostali čas ~ 24,7 sekunde (24,500 KB / 992 KB).
• Pri 77 sekundah: efektivna hitrost = ~ 983 KB (59.000 KB / 60), ki traja približno 24,4 sekunde (24,000 KB / 983 KB).
• Pri 78 sekundah: efektivna hitrost = 975 KB (58.500 KB / 60), ki traja preostanek ~ 24,1 sekunde (23,500 KB / 975 KB).

Vidite lahko vzorec, ki se pojavlja tukaj, saj se dip v hitrosti prenosa počasi vključi v povprečje, ki se uporablja za oceno preostalega časa. V skladu s to metodo, če je dip trajal le 10 sekund in se nato vrnil na 1 MB / s, ni verjetno, da bi uporabnik opazil razliko (razen za zelo majhno stojalo v ocenjenem času odštevanja).

Pridobivanje medeninastih žebljičkov - to je preprosto metodologija za posredovanje informacij končnemu uporabniku za dejanski vzrok.

Ne morete natančno določiti nekaj, kar je nedeterministično

Navsezadnje se netočnost v napredku zmanjšuje na dejstvo, da skuša določiti čas za nekaj, kar je nedeterministično. Ker računalniki obdelujejo opravila na zahtevo in v ozadju, je skoraj nemogoče vedeti, kateri sistemski viri bodo na voljo v katerem koli trenutku v prihodnosti - in razpoložljivost sistemskih virov je potrebna za dokončanje vsake naloge.

V drugem primeru predpostavimo, da izvajate nadgradnjo programa na strežniku, ki izvaja dokaj intenzivno posodobitev baze podatkov. Med tem postopkom posodobitve uporabnik nato pošlje zahtevo v drugo bazo podatkov, ki se izvaja v tem sistemu. Zdaj morajo strežniški viri, posebej za bazo podatkov, obdelati zahteve za vašo nadgradnjo kot tudi za uporabljeno poizvedbo - scenarij, ki bo zagotovo škodljiv za čas izvedbe. Poleg tega lahko uporabnik sproži zahtevo za prenos velikih datotek, ki bi obdavčila pretočnost skladiščenja, ki bi tudi zmanjšala zmogljivost. Ali bi se lahko začela načrtovana naloga, ki izvede proces, ki je intenziven v spominu. Dobiš idejo.

Morda bolj realističen primer za vsakdanje uporabnike - razmislite o zagonu Windows Update ali pregledu virusov. Obe operaciji izvajata operacije z intenzivnimi viri v ozadju. Posledično je napredek vsakega izdelka odvisen od tega, kaj počne uporabnik. Če berete e-pošto med izvajanjem, bo verjetno povpraševanje po sistemskih virih nizko in vrstica napredka se bo dosledno premikala. Po drugi strani pa, če se ukvarjate z urejanjem grafike, bo vaše povpraševanje po sistemskih virih veliko večje, kar bo povzročilo shizofreno gibanje napredka..

Na splošno je preprosto, da ni kristalne krogle. Niti sistem sam ne ve, v kakšni obremenitvi bo v prihodnosti.

Konec koncev, res ni pomembno

Namen vrstice napredka je, da kažejo, da je bil dejansko dosežen napredek in da zadevni proces ni obešen. Lepo je, ko je kazalnik napredka točen, vendar je običajno le manjša motnja, ko ni. Razvijalci v večini primerov ne bodo namenili veliko časa in truda algoritmom napredka, saj, če odkrito, obstajajo veliko pomembnejše naloge.

Seveda imate vso pravico, da vas moti, ko se vrstica napredka takoj premakne na 99% in potem počakate 5 minut za preostali odstotek. Ampak, če zadevni program deluje dobro na splošno, samo spomnite, da je imel razvijalec svoje prednostne naloge naravnost.