Miks on edusammud nii ebatäpsed?

Esmapilgul tundub, et täpse ajahinnangu loomine peaks olema üsna lihtne. Lõppude lõpuks, edenemisriba tootev algoritm teab kõiki ülesandeid, mida ta peab enne tähtaega tegema ... õigus?

Enamasti on tõsi, et lähtealgoritm teab, mida ta peab enne tähtaega tegema. Kuid iga sammu sooritamiseks kuluva aja kinnitamine on väga raske, kui mitte praktiliselt võimatu ülesanne.

Kõik ülesanded ei ole võrdsed

Lihtsaim viis edenemisriba rakendamiseks on kasutada loenduri graafilist esitust. Kui protsendimäära arvutatakse lihtsalt kui Lõpetatud ülesanded / ülesannete koguarv. Kuigi see teeb loogilisest mõttes esimese mõtte, on oluline meeles pidada, et (ilmselt) mõned ülesanded lõpevad kauem.

Arvestage järgmisi paigaldaja ülesandeid:

1. Loo kausta struktuur.
2. Dekompresseerige ja kopeerige 1 GB väärtuses faile.
3. Loo registrikirjed.
4. Loo algmenüü kirjed.

Selles näites viiakse etapid 1, 3 ja 4 lõpule väga kiiresti, samas kui etapp 2 võtab aega. Nii et lihtsa loendusega töötav edenemisriba hüppab väga kiiresti 25% -ni, seiskub veidi, kui 2. etapp töötab, ja seejärel hüpata 100% -ni peaaegu kohe.

Selline rakendamine on tõepoolest üsna tavaline edenemisribade seas, sest nagu eespool öeldud, on seda lihtne rakendada. Kuid nagu näete, on selle suhtes ebaproportsionaalsed ülesanded, mis väänavad tegelik protsent, mis on seotud järelejäänud ajaga.

Selle ümber töötamiseks võivad mõned edenemisriba kasutada rakendusi, kus samme kaalutakse. Vaadake ülaltoodud samme, kus igale sammule on määratud suhteline kaal:

1. Loo kausta struktuur. [Kaal = 1]
2. Dekompresseerige ja kopeerige 1 GB väärtuses faile. [Kaal = 7]
3. Loo registrikirjed. [Kaal = 1]
4. Loo algmenüü kirjed. [Kaal = 1]

Kasutades seda meetodit, liiguks edenemisriba sammudega 10% (kui kogumass on 10), kusjuures sammud 1, 3 ja 4 liigutavad baari 10% lõpetamisel ja etapp 2 liigutab seda 70%. Kuigi kindlasti pole see täiuslik, on sellised meetodid lihtsaks viisiks, kuidas lisada edenemisriba protsendile veidi rohkem täpsust.

Eelmised tulemused ei garanteeri tulevikku

Mõtle lihtsa näite juurde, paludes teil lugeda kuni 50-ni, kui ma kasutan stopperit ajal. Oletame, et loete 25 sekundiks 10 sekundiga. Oleks mõistlik eeldada, et ülejäänud arvud loendatakse veel 10 sekundi jooksul, nii et edenemisriba jälgimine näitaks 50%, 10 sekundiga alles.

Kui teie arv jõuab 25-ni, siis ma hakkan tennist pallid viskama. Tõenäoliselt see murdab teie rütmi, sest teie kontsentratsioon on liikunud rangelt loendavatest numbritest kuni kõrvale kalduvate pallideni. Eeldades, et teil on võimalik jätkata lugemist, on teie tempo kindlasti veidi aeglustunud. Nüüd on edenemisriba veel liikumas, kuid palju aeglasemas tempos, kui hinnanguline aeg jääb seisma või tõuseb kõrgemale.

Praktilisema näite saamiseks kaaluge faili allalaadimist. Praegu laadite alla 100 MB faili kiirusega 1 MB / s. See on hinnanguline valmimisaja määramine väga lihtne. Aga 75% sealt, mõned võrgukoormuse tabamused ja teie allalaadimiskiirus langeb 500 KB / s.

Sõltuvalt sellest, kuidas brauser ülejäänud aja arvutab, võib teie ETA koheselt minna 25 sekundist 50 sekundini (kasutades ainult praegust olekut: Järelejäänud suurus / allalaadimise kiirus) või tõenäoliselt kasutab brauser jooksvat keskmist algoritmi, mis kohandaks ülekandekiiruse kõikumisi ilma dramaatilisi hüppeid kasutajale näitamata.

Faili allalaadimisega seotud jooksva algoritmi näide võib toimida nii:

• Ülekandekiirust viimase 60 sekundi jooksul mäletatakse uusima väärtusega, mis asendab vanimat (nt 61. väärtus asendab esimest).
• Arvutamisel on efektiivne ülekandekiirus nende mõõtmiste keskmine.
• Ülejäänud aeg arvutatakse järgmiselt: Suurus jääb / efektiivne allalaadimise kiirus

Nii et kasutades meie stsenaariumi (lihtsuse huvides kasutame 1 MB = 1 000 KB):

• 75 sekundi jooksul allalaadimisest oleks meie 60 mäletatud väärtust 1 000 KB. Efektiivne ülekande määr on 1000 KB (60 000 KB / 60), mis annab järelejäänud 25 sekundi (25 000 KB / 1000 KB).
• 76 sekundi pärast (kui ülekandekiirus langeb 500 KB-ni) muutub tegelik allalaadimise kiirus ~ 992 KB (59,5 KB / 60), mis annab aega ~ 24,7 sekundit (24 500 KB / 992 KB).
• 77 sekundiga: efektiivne kiirus = ~ 983 KB (59 000 KB / 60), mis annab aega ~ 24,4 sekundit (24 000 KB / 983 KB).
• 78 sekundiga: efektiivne kiirus = 975 KB (58,500 KB / 60), mis annab aega ~ 24,1 sekundiks (23 500 KB / 975 KB).

Siin näete, et allalaadimiskiirus on aeglaselt sisestatud keskmisesse, mida kasutatakse järelejäänud aja hindamiseks. Selle meetodi puhul, kui dip kestis ainult 10 sekundit ja seejärel naaseb 1 MB / s, ei ole kasutaja tõenäoliselt erinevust täheldanud (välja arvatud väga väikese seiskumise korral hinnangulises aja arvestuses).

Saabumine messingist lipsudesse - see on lihtsalt metoodika teabe edastamiseks lõppkasutajale tegeliku põhjuse kohta…

Sa ei saa täpselt kindlaks määrata midagi, mis on mitteterministlik

Lõppkokkuvõttes langeb edenemisriba ebatäpsus sellele, et ta püüab kindlaks määrata aja, mis on midagi mitteterminaalset. Kuna arvutid töötlevad ülesandeid nii nõudmisel kui ka taustal, on peaaegu võimatu teada, millised süsteemi ressursid on tulevikus kättesaadavad - ja mis tahes ülesande täitmiseks on vaja süsteemi ressursse..

Kasutades teist näidet, oletame, et kasutate programmi uuendamist serveris, mis täidab üsna intensiivset andmebaasi värskendust. Selle värskendamisprotsessi ajal saadab kasutaja seejärel nõudliku päringu teisele andmebaasis, mis töötab selles süsteemis. Nüüd peavad spetsiaalselt andmebaasi serveriressursid töötlema nii teie uuenduse kui ka kasutaja algatatud päringu päringuid - stsenaariumi, mis kindlasti on vastastikku kahjulik teostamise ajale. Alternatiivselt võib kasutaja algatada suure failiedastuse taotluse, mis maksustaks ka salvestamise läbilaskevõimet, mis kahjustaks ka jõudlust. Või planeeritud ülesanne võib käivitada mälu intensiivse protsessi. Sa saad idee.

Võimalik, et igapäevase kasutaja realistlikum näide - kaaluge Windowsi värskenduse või viirusekontrolli käivitamist. Mõlemad toimingud teostavad taustal ressursimahukaid operatsioone. Selle tulemusena sõltub iga tootja tehtud edusammud sellest, mida kasutaja hetkel teeb. Kui loete oma e-posti, kui see töötab, on tõenäoliselt madal süsteemiressursside nõue ja edenemisriba liigub järjekindlalt. Teisest küljest, kui te teete graafilist redigeerimist, siis on teie süsteemiressursside nõudlus palju suurem, mis põhjustab edenemisriba liikumise skisofreenia..

Üldiselt on lihtsalt see, et kristallkuul puudub. Isegi süsteem ise ei tea, millist koormust see tulevikus mingil hetkel allub.

Lõppkokkuvõttes see tegelikult ei tähenda

Edenemisriba eesmärk on hästi näidata, et edusamme on tõepoolest tehtud ja vastav protsess pole riputatud. On tore, kui edenemise näitaja on täpne, kuid tavaliselt on see vaid vähene pahameel, kui see pole. Enamasti ei kavatse arendajad pühendada palju aega ja vaeva edenemisriba algoritmidele, sest ausalt öeldes on palju olulisemaid ülesandeid, mis kulutavad aega.

Loomulikult on teil täielik õigus olla pahane, kui edenemisriba hüppab koheselt 99% -ni ja siis ootab 5% ülejäänud ühe protsendi eest. Aga kui vastav programm toimib hästi, tuletage meelde, et arendaja prioriteedid olid sirged.