Zašto su trake napretka tako netočne?

Na prvi pogled, čini se da bi generiranje točne procjene vremena trebalo biti prilično lako. Uostalom, algoritam koji stvara traku napretka zna sve zadatke koje treba obaviti prije vremena ... točno?

Za veći dio, istina je da izvorni algoritam zna što treba učiniti prije vremena. Međutim, namještanje vremena koje je potrebno za izvođenje svakog koraka je vrlo težak, ako ne i gotovo nemoguć zadatak.

Svi zadaci nisu jednaki

Najjednostavniji način implementacije trake napretka je korištenje grafičkog prikaza brojača zadataka. Kada se postotak potpune izračuna jednostavno Dovršeni zadaci / ukupan broj zadataka. Premda ovo na prvi pogled čini logičan smisao, važno je zapamtiti da (očito) nekim zadacima treba više vremena.

Razmotrite sljedeće zadatke koje izvodi instalacijski program:

1. Stvorite strukturu mapa.
2. Dekomprimirajte i kopirajte datoteke od 1 GB.
3. Stvorite stavke registra.
4. Stvorite stavke izbornika Start.

U ovom primjeru, koraci 1, 3 i 4 će se završiti vrlo brzo, dok će korak 2 potrajati neko vrijeme. Dakle, traka napretka koja radi na jednostavnom brojanju skočila bi na 25% vrlo brzo, zaustavila se malo dok je korak 2 radio, a zatim skočio na 100% gotovo odmah.

Ova vrsta implementacije je zapravo prilično uobičajena među progresima jer, kao što je gore navedeno, lako je implementirati. Međutim, kao što možete vidjeti, ono je podložno nesrazmjernim zadacima koji iskrivljuju stvaran postotak napretka koji se odnosi na preostalo vrijeme.

Da biste zaobišli ovo, neke trake napretka mogu koristiti implementacije u kojima su koraci ponderirani. Razmotrite gore navedene korake u kojima je relativnoj težini dodijeljen svaki korak:

1. Stvorite strukturu mapa. [Težina = 1]
2. Dekomprimirajte i kopirajte datoteke od 1 GB. [Težina = 7]
3. Stvorite stavke registra. [Težina = 1]
4. Stvorite stavke izbornika Start. [Težina = 1]

Koristeći ovu metodu, traka napretka kretala bi se u koracima od 10% (budući da je ukupna težina 10) s koracima 1, 3 i 4 pomicanjem šipke 10% nakon završetka i koraka 2 pomicanjem 70%. Iako zasigurno nije savršen, metode kao što je ovaj su jednostavan način za dodavanje malo više točnosti u postotak napredak bar.

Prethodni rezultati ne jamče buduće performanse

Razmislite o jednostavnom primjeru da od vas tražim da brojite do 50 dok koristim štopericu kako bih vas proveo u vremenu. Recimo da brojite do 25 za 10 sekundi. Bilo bi razumno pretpostaviti da ćete brojati preostale brojeve u dodatnih 10 sekundi, tako da će praćenje trake napretka pokazati 50% završetka s preostalih 10 sekundi.

Međutim, kada broj bodova dosegne 25, počinjem bacati teniske loptice na vas. Vjerojatno, to će slomiti vaš ritam dok se vaša koncentracija preselila od strogo brojanja brojeva do izbjegavanja loptica koje vam bacaju put. Pod pretpostavkom da možete nastaviti s brojanjem, vaš ritam je zasigurno malo usporio. Tako je sada traka napretka još uvijek u pokretu, ali mnogo sporijim tempom, dok procijenjeno vrijeme ostaje ili u mirovanju ili se zapravo uspinje više.

Za praktičniji primjer navedite preuzimanje datoteke. Trenutno preuzimate datoteku od 100 MB brzinom od 1 MB / s. To je vrlo lako odrediti procijenjeno vrijeme završetka. No, 75% puta tamo, neke mreže zagušenja pogodaka i vaš download stopa pada do 500 KB / s.

Ovisno o tome kako preglednik izračunava preostalo vrijeme, vaša ETA trenutačno može ići od 25 sekundi do 50 sekundi (koristeći samo trenutno stanje: Veličina / Preostala brzina) ili, najvjerojatnije, preglednik upotrebljava algoritam okretnog prosjeka koji bi se prilagodio za fluktuacije brzine prijenosa bez prikazivanja dramatičnih skokova korisniku.

Primjer algoritma za valjanje u vezi s preuzimanjem datoteke može raditi ovako:

• Brzina prijenosa za prethodnih 60 sekundi pamti se s najnovijom vrijednošću koja zamjenjuje najstarije (npr. 61. vrijednost zamjenjuje prvu).
• Efektivna stopa prijenosa u svrhu izračuna je prosjek tih mjerenja.
• Preostalo vrijeme izračunava se kao: Veličina preostale / Efektivna brzina preuzimanja

Dakle, koristeći gore navedeni scenarij (radi jednostavnosti koristit ćemo 1 MB = 1.000 KB):

• Nakon 75 sekundi preuzimanja, svaka od 60 zapamćenih vrijednosti iznosila bi 1000 KB. Efektivna stopa prijenosa je 1.000 KB (60.000 KB / 60) što daje preostalo vrijeme od 25 sekundi (25.000 KB / 1.000 KB).
• U 76 sekundi (gdje brzina prijenosa pada na 500 KB), efektivna brzina preuzimanja postaje ~ 992 KB (59,500 KB / 60) što daje preostalo vrijeme od ~ 24,7 sekundi (24,500 KB / 992 KB).
• U 77 sekundi: Efektivna brzina = ~ 983 KB (59,000 KB / 60) i preostalo vrijeme od ~ 24,4 sekundi (24,000 KB / 983 KB).
• U 78 sekundi: Efektivna brzina = 975 KB (58,500 KB / 60) što daje preostalo vrijeme od ~ 24,1 sekundi (23,500 KB / 975 KB).

Možete vidjeti uzorak koji se pojavljuje ovdje, jer se dip u brzini preuzimanja polako uključuje u prosjek koji se koristi za procjenu preostalog vremena. Prema ovoj metodi, ako je dip trajao samo 10 sekundi, a zatim se vratio na 1 MB / s, malo je vjerojatno da će korisnik primijetiti razliku (osim za vrlo mali zastoj u predviđenom vremenskom odbrojavanju).

Kako doći do mesinganih čavlića - to je jednostavno metodologija za prosljeđivanje informacija krajnjem korisniku za stvarni uzrok ...

Ne možete točno odrediti nešto što je nedeterminističko

U konačnici, netočnost u napretku se svodi na činjenicu da pokušava odrediti vrijeme za nešto što je nedeterminističko. Budući da računala obrađuju zadatke i na zahtjev iu pozadini, gotovo je nemoguće znati koji će resursi sustava biti dostupni u bilo kojem trenutku u budućnosti - a dostupnost sistemskih resursa potrebna je za izvršavanje bilo kojeg zadatka.

Koristeći drugi primjer, pretpostavimo da pokrećete nadogradnju programa na poslužitelju koji izvodi prilično intenzivno ažuriranje baze podataka. Tijekom ovog procesa ažuriranja, korisnik zatim šalje zahtjevan zahtjev u drugu bazu podataka koja se izvodi na ovom sustavu. Sada resursi poslužitelja, posebno za bazu podataka, moraju obrađivati ​​zahtjeve za nadogradnju kao i za upite koje je pokrenuo korisnik - scenarij koji će sigurno biti uzajamno štetan za vrijeme izvođenja. Alternativno, korisnik može pokrenuti zahtjev za prijenos velikih datoteka koji će oporezivati ​​propusnost pohrane koja bi također umanjila učinkovitost. Ili bi se mogao započeti planirani zadatak koji obavlja proces intenzivne memorije. Dobio si ideju.

Kao, možda, realniji primjer za svakodnevnog korisnika - razmislite o pokretanju servisa Windows Update ili skeniranja virusa. Obje ove operacije izvode operacije s intenzivnim korištenjem resursa u pozadini. Kao rezultat toga, napredak koji svaki napredak ovisi o tome što korisnik trenutno radi. Ako čitate e-poštu dok se pokreće, najvjerojatnije će potražnja za resursima sustava biti niska, a traka napretka će se dosljedno kretati. S druge strane, ako radite uređivanje grafike, vaša potražnja za resursima sustava bit će mnogo veća što će uzrokovati shizofreniju pokreta napredne trake.

Sve u svemu, jednostavno je da nema kristalne kugle. Ni sam sustav ne zna pod kojim će opterećenjem biti u bilo kojem trenutku u budućnosti.

U konačnici, to stvarno nije važno

Namjera stupca napretka je da, dobro, ukazuju na to da je doista postignut napredak i da dotični proces nije obješen. Lijepo je kada je pokazatelj napretka točan, ali obično je to samo neznatna smetnja kada nije. U većini slučajeva, programeri ne namjeravaju posvetiti mnogo vremena i truda u algoritme napredne trake jer, iskreno, ima mnogo važnijih zadataka za trošenje vremena na.

Naravno, imate svako pravo biti uzrujani kada traka napretka skoči na 99% potpunog trenutka i onda vas čeka 5 minuta za preostalih jedan posto. Ali ako odgovarajući program dobro funkcionira, samo se podsjetite da je programer imao svoje prioritete.