Kodėl pažangos strypai yra tokie netikslūs?

Iš pirmo žvilgsnio atrodo, kad tikslaus laiko įvertinimo sukūrimas turėtų būti gana lengvas. Galų gale, progreso juostą gaminantis algoritmas žino visas užduotis, kurias reikia atlikti prieš laiką ... teisingai?

Daugeliu atvejų tiesa, kad šaltinio algoritmas žino, ką reikia daryti iš anksto. Tačiau laikas, kurį reikės atlikti kiekvienam žingsniui atlikti, yra labai sudėtinga, o ne beveik neįmanoma.

Visos užduotys nėra sukurtos vienodos

Paprasčiausias būdas pasiekti progreso juostą yra grafinio užduočių skaitiklio pateikimas. Kai procentinė dalis yra tiesiog apskaičiuojama kaip Užbaigtos užduotys / bendras užduočių skaičius. Nors tai logiška prasme dėl pirmosios minties, svarbu prisiminti, kad (akivaizdu, kad kai kurios užduotys užtrunka ilgiau).

Apsvarstykite šias užduotis, kurias atlieka montuotojas:

1. Sukurti aplanko struktūrą.
2. Ištrinkite ir nukopijuokite 1 GB vertės failų.
3. Kurkite registro įrašus.
4. Sukurti pradžios meniu įrašus.

Šiame pavyzdyje 1, 3 ir 4 žingsniai būtų užbaigti labai greitai, o 2 veiksmas truks šiek tiek laiko. Taigi pažangos juosta, veikianti paprastu skaičiumi, labai greitai peršoktų į 25%, truputį sustos, o 2-as žingsnis veikia, o tada iš karto pereikite prie 100%.

Šis įgyvendinimo būdas iš tikrųjų yra gana paplitęs tarp pažangos juostų, nes, kaip jau minėta, tai lengva įgyvendinti. Tačiau, kaip matote, jai tenka neproporcingai didelių užduočių tikras pažangos procentas, susijęs su likusiu laiku.

Jei norite tai padaryti, kai kurios pažangos juostos gali naudoti įgyvendinimą, kai žingsniai yra sveriami. Apsvarstykite aukščiau nurodytus veiksmus, kai kiekvienam etapui priskiriamas santykinis svoris:

1. Sukurti aplanko struktūrą. [Svoris = 1]
2. Ištrinkite ir nukopijuokite 1 GB vertės failų. [Svoris = 7]
3. Kurkite registro įrašus. [Svoris = 1]
4. Sukurti pradžios meniu įrašus. [Svoris = 1]

Naudojant šį metodą, pažangos juosta judėtų po 10% (kaip bendras svoris yra 10), kai 1, 3 ir 4 žingsniai perkelia juostą 10%, o 2 žingsnis - 70%. Nors tikrai ne tobula, tokie metodai yra paprastas būdas pridėti šiek tiek daugiau tikslumo progreso juostos procentui.

Ankstesni rezultatai negarantuoja ateities rezultatų

Apsvarstykite paprastą pavyzdį, kuriame prašau skaičiuoti iki 50, o aš naudoju chronometrą. Tarkime, jūs skaičiuojate iki 25 per 10 sekundžių. Būtų protinga manyti, kad likusius skaičius suskaičiuosite per 10 sekundžių, todėl pažangos juostos stebėjimas parodys 50%, o liko 10 sekundžių.

Tačiau, kai jūsų skaičius pasiekia 25, aš pradedu mesti teniso kamuoliukus. Tikėtina, kad tai sulaužys jūsų ritmą, nes jūsų koncentracija persikėlė iš griežtai skaičiuojančių numerių į vengiančius kamuolius. Darant prielaidą, kad galite tęsti skaičiavimą, jūsų tempas šiek tiek sulėtėjo. Taigi, pažangos juosta vis dar juda, tačiau daug lėčiau, kai numatomas laikas lieka arba sustabdytas, arba iš tiesų aukštesnis.

Norėdami gauti daugiau praktinio pavyzdžio, apsvarstykite failo atsisiuntimą. Šiuo metu atsisiunčiate 100 MB failą 1 MB / s greičiu. Tai labai lengva nustatyti numatomą užbaigimo laiką. Tačiau 75 proc. Ten esančių vietų, kai kurie tinklo perkrovimai pasiekiami, o atsisiuntimo greitis nukrenta iki 500 KB / s.

Priklausomai nuo to, kaip naršyklė apskaičiuoja likusį laiką, jūsų ETA gali iš karto pereiti nuo 25 sekundžių iki 50 sekundžių (naudojant tik dabartinę būseną: Likęs dydis / atsisiuntimo greitis) arba, greičiausiai, naršyklė naudoja riedėjimo vidutinį algoritmą, kuris pritaikytų perdavimo spartos svyravimams neparodant dramatiškų šuolių naudotojui.

Riedėjimo algoritmo, susijusio su failo parsisiuntimu, pavyzdys gali būti toks:

• Perdavimo greitis per pastarąsias 60 sekundžių prisimenamas naujausia verte, pakeičiančia seniausią (pvz., 61-oji vertė pakeičia pirmąjį).
• Efektyvus perdavimo greitis apskaičiavimo tikslais yra šių matavimų vidurkis.
• Likęs laikas apskaičiuojamas taip: Likęs dydis / efektyvus atsisiuntimo greitis

Taigi, naudodami pirmiau pateiktą scenarijų (paprastumo dėlei, naudosime 1 MB = 1 000 KB):

• 75 sekundės į atsisiuntimą, mūsų 60 prisimintų verčių būtų 1 000 KB. Efektyvus siuntimo greitis yra 1 000 KB (60 000 KB / 60), kuris duoda 25 sekundžių (25 000 KB / 1000 KB).
• 76 sekundėmis (kai perkėlimo greitis sumažėja iki 500 KB), faktinis atsisiuntimo greitis tampa ~ 992 KB (59,500 KB / 60), kuris duoda likusią laiką ~ 24,7 sekundės (24,5 KB / 992 KB).
• 77 sekundėmis: efektyvus greitis = ~ 983 KB (59 000 KB / 60), kurio likęs laikas yra ~ 24,4 sekundės (24 000 KB / 983 KB).
• 78 sekundėmis: efektyvus greitis = 975 KB (58,500 KB / 60), suteikiantis likusią laiką ~ 24,1 sekundės (23 500 KB / 975 KB).

Galite matyti čia atsirandantį modelį, nes parsisiuntimo greitis lėtai įtraukiamas į vidurkį, kuris naudojamas likusiam laiko įvertinimui. Pagal šį metodą, jei kritimas truko tik 10 sekundžių ir tada grįžo į 1 MB / s, vartotojas greičiausiai nepastebės skirtumo (išskyrus labai nedidelį sustojimą numatytu laiku).

Patekimas į žalvario sąvaržą - tai tiesiog metodika, skirta galutiniam vartotojui perduoti informaciją apie faktinę pagrindinę priežastį ...

Jūs negalite tiksliai nustatyti kažko, kas nėra neceterministinis

Galų gale, pažangos juostos netikslumas susilpnėja su tuo, kad jis stengiasi nustatyti laiką, kuris yra kažkas, kas nėra nenuoseklus. Kadangi kompiuteriai apdoroja užduotis tiek pagal paklausą, tiek fone, beveik neįmanoma žinoti, kokie sistemos ištekliai bus prieinami bet kuriuo metu ateityje - ir būtinas sistemos išteklių prieinamumas, kad bet kuri užduotis būtų užbaigta.

Naudodami kitą pavyzdį, tarkime, kad naudojate programos atnaujinimą serveryje, kuris atlieka gana intensyvų duomenų bazės atnaujinimą. Per šį naujinimo procesą naudotojas tada siunčia reikiamą užklausą kitai duomenų bazei, veikiančiai šioje sistemoje. Dabar serverio ištekliai, būtent duomenų bazei, turi apdoroti užklausas tiek atnaujinti, tiek naudotojo inicijuotą užklausą - scenarijų, kuris tikrai bus abipusiškai žalingas vykdymo laikui. Be to, vartotojas gali inicijuoti didelį failų perkėlimo prašymą, kuris apmokestintų saugojimo našumą, kuris taip pat sumažintų našumą. Arba suplanuota užduotis gali atverti atminties intensyvų procesą. Jūs gaunate idėją.

Kaip tikriausiai, realesnis kasdienio naudotojo pavyzdys - apsvarstyti galimybę paleisti „Windows“ naujinimą ar virusų nuskaitymą. Abi šios operacijos atlieka daug išteklių reikalaujančias operacijas fone. Todėl kiekvienos padėties pažanga priklauso nuo to, ką vartotojas daro tuo metu. Jei skaitote el. Laišką, kai tai vyksta, greičiausiai sistemos išteklių paklausa bus maža ir pažangos juosta bus nuosekliai judama. Kita vertus, jei dirbate su grafikos redagavimu, tuomet jūsų sistemos išteklių poreikis bus daug didesnis, o dėl to progreso juostos judėjimas bus šizofreninis.

Apskritai, paprasčiausiai nėra kristalinio rutulio. Net pati sistema nežino, kokia apkrova bus bet kuriuo metu ateityje.

Galų gale, tai tikrai nėra svarbu

Pažangos juostos tikslas yra, gerai, nurodyti, kad pažanga iš tiesų daroma ir atitinkamas procesas nėra pakabintas. Malonu, kai pažangos rodiklis yra tikslus, bet paprastai tai yra tik nedidelis erzinimas, kai tai nėra. Daugeliu atvejų kūrėjai neketina skirti daug laiko ir pastangų pažangos juostos algoritmams, nes atvirai kalbant, yra daug svarbesnių užduočių praleisti laiką.

Žinoma, jūs turite visas teises būti erzina, kai progreso juosta staigiai pereina į 99%, o po to palaukite 5 minutes likusiam 1%. Tačiau, jei atitinkama programa veikia gerai, tiesiog priminkite sau, kad kūrėjas turėjo savo prioritetus tiesiai.