Z väčšej časti je pravda, že zdrojový algoritmus vie, čo musí urobiť pred časom. Určenie času, ktorý bude potrebný na vykonanie každého kroku, je však veľmi ťažké, ak nie úplne nemožné.
Všetky úlohy nie sú vytvorené rovnaké
Najjednoduchší spôsob implementácie pruhu postupu je použitie grafického znázornenia počítadla úloh. Kde je percento úplné jednoducho vypočítané ako Dokončené úlohy / celkový počet úloh, Zatiaľ čo toto je logický zmysel pre prvú myšlienku, je dôležité mať na pamäti, že (iste) niektoré úlohy trvajú dlhšie.
Zvážte nasledujúce úlohy vykonané inštalatérom:
- Vytvorte štruktúru priečinkov.
- Dekomprimujte a kopírujte 1 GB súborov.
- Vytvorte položky databázy Registry.
- Vytvorte položky štartovnej ponuky.
V tomto príklade sa kroky 1, 3 a 4 dokončia veľmi rýchlo, zatiaľ čo krok 2 bude trvať určitý čas. Takže pokrok v bare, ktorý pracuje na jednoduchom počte, by sa veľmi rýchlo dostal na 25%, za chvíľu stál, zatiaľ čo krok 2 funguje a potom skoro až na 100%.
Tento typ implementácie je vlastne pomerne častý medzi pruhy pokroku, pretože, ako bolo uvedené vyššie, je ľahké ho implementovať. Ako však vidíte, podlieha neprimeraným úlohám skutočný percento pokroku, pokiaľ ide o zostávajúci čas.
Ak chcete toto vyriešiť, niektoré pruhy pokroku môžu používať implementácie, v ktorých sú vážené kroky. Uvažujme vyššie uvedené kroky, kde je priradená relatívna váha každému kroku:
- Vytvorte štruktúru priečinkov. [Hmotnosť = 1]
- Dekomprimujte a kopírujte 1 GB súborov. [Hmotnosť = 7]
- Vytvorte položky databázy Registry. [Hmotnosť = 1]
- Vytvorte položky štartovnej ponuky. [Hmotnosť = 1]
Použitím tejto metódy sa priebežná lišta pohybuje v krokoch po 10% (celková hmotnosť je 10), pričom kroky 1, 3 a 4 pohybujú tyčou o 10% po ukončení a krok 2 sa pohybuje o 70%. Zatiaľ čo to určite nie je dokonalé, metódy, ako je tento, sú jednoduchým spôsobom, ako pridať o niečo presnejšie percento ukazovateľa priebehu.
Predchádzajúce výsledky nezaručujú budúci výkon
Zoberme si jednoduchý príklad toho, že vás žiadam, aby ste počítať na 50, zatiaľ čo som použil stopky na čas, ktorý ste vy. Povedzme, že počítate na 25 za 10 sekúnd. Bolo by rozumné predpokladať, že zostávajúce čísla budú spočítané o ďalších 10 sekúnd, takže ukazovateľ priebehu sledovania to bude ukazovať 50% kompletné s 10 sekundami zostávajúcich.
Akonáhle sa váš počet dostane do 25 rokov, začnem vám hádzať tenisové loptičky. Je pravdepodobné, že to prelomí váš rytmus, pretože vaša koncentrácia sa presunula od prísneho počítania čísel na uhýbanie loptičiek, ktoré vám uvrhli cestu. Za predpokladu, že ste schopní pokračovať v započítaní, vaše tempo sa určite spomalilo. Takže teraz sa priebežný pruh stále pohybuje, ale oveľa pomalšie, s predpokladaným časom, ktorý zostane buď zastavený, alebo dokonca vyššia.
Pre praktickejší príklad zvážte stiahnutie súboru. Momentálne sťahujete 100 MB súbor vo výške 1 MB / s. Je veľmi ľahké určiť odhadovaný čas dokončenia. Ale 75% spôsobu, niektoré hity preťaženia siete a rýchlosť sťahovania klesne na 500 KB / s.
V závislosti od toho, ako prehliadač vypočíta zostávajúci čas, vaša ETA by mohla okamžite prejsť z 25 sekúnd na 50 sekúnd (len v súčasnom stave: Zostávajúca veľkosť / rýchlosť sťahovania) alebo s najväčšou pravdepodobnosťou používa prehliadač algoritmus valcového priemeru, ktorý by sa prispôsobil kolísaniu prenosovej rýchlosti bez zobrazenia dramatických skokov užívateľovi.
Príklad algoritmu o prevzatí súboru by mohol fungovať takto:
- Rýchlosť prenosu za posledných 60 sekúnd sa zapamätá s najnovšou hodnotou, ktorá nahrádza najstaršiu hodnotu (napríklad 61. hodnota nahrádza prvú hodnotu).
- Efektívna prenosová rýchlosť na účely výpočtu je priemerom týchto meraní.
- Zostávajúci čas sa vypočíta ako: Zostávajúca veľkosť / efektívna rýchlosť sťahovania
Takže pomocou nášho scenára vyššie (v záujme jednoduchosti použijeme 1 MB = 1 000 KB):
- Po uplynutí 75 sekúnd do stiahnutia by naše 60 pamätalých hodnôt malo mať hodnotu 1000 KB. Efektívna rýchlosť prenosu je 1 000 KB (60 000 KB / 60), čo prináša zostávajúci čas 25 sekúnd (25 000 KB / 1 000 KB).
- Za 76 sekúnd (kde rýchlosť prenosu klesne na 500 KB) sa rýchlosť sťahovania stáva ~ 992 KB (59,500 KB / 60), čím zostáva zostávajúci čas ~ 24,7 sekundy (24,500 KB / 992 KB).
- Za 77 sekúnd: Efektívna rýchlosť = ~ 983 KB (59 000 KB / 60), čo dáva zostávajúci čas ~ 24,4 sekundy (24 000 KB / 983 KB).
- Za 78 sekúnd: Efektívna rýchlosť = 975 KB (58,500 KB / 60), z čoho zostáva zostávajúci čas ~ 24,1 sekundy (23,500 KB / 975 KB).
Tu vidíte vzor, ktorý sa tu objavuje, pretože ponorenie rýchlosti sťahovania je pomaly začlenené do priemeru, ktorý sa používa na odhad zostávajúceho času. Pri tejto metóde, ak ponor trval len 10 sekúnd a potom sa vráti na 1 MB / s, je pravdepodobné, že používateľ si nevšimne rozdiel (s výnimkou veľmi malého stánku v odhadovanom časovom odpočítavaní).
Dostať sa k mosadzným prístrojom - ide len o metodiku prenosu informácií konečnému používateľovi o skutočnej základnej príčine …
Nemôžete presne určiť niečo, čo je nedeterministické
Nakoniec, nepresnosť v pokrokovom riadku klesá na skutočnosť, že sa snaží určiť čas na niečo, čo je nedeterministické. Keďže počítače spracovávajú úlohy na požiadanie i na pozadí, je takmer nemožné vedieť, aké systémové prostriedky budú k dispozícii v budúcnosti - a to je dostupnosť systémových zdrojov, ktoré sú potrebné na dokončenie akejkoľvek úlohy.
Ak použijete iný príklad, predpokladajme, že používate aktualizáciu programu na serveri, ktorý vykonáva pomerne intenzívnu aktualizáciu databázy. Počas tohto procesu aktualizácie používateľ pošle náročnú požiadavku do inej databázy spustenej v tomto systéme. Teraz serverové zdroje, konkrétne pre databázu, musia spracovávať požiadavky na aktualizáciu, ako aj na dotaz spustený používateľom - scenár, ktorý bude určite vzájomne poškodzujúci čas vykonávania. Alternatívne by mohol používateľ iniciovať veľký žiadosť o prenos súborov, ktorá by zdanila kapacitu úložiska, ktorá by tiež znížila výkonnosť. Alebo by sa mohla spustiť naplánovaná úloha, ktorá vykonáva proces s intenzívnou pamäťou. Získate nápad.
Ako pravdepodobnejšia realistická inštancia pre každodenného používateľa - zvážte spustenie služby Windows Update alebo antivírusového vyhľadávania. Obe tieto operácie vykonávajú operácie náročné na zdroje na pozadí. Výsledkom toho je, že každý postup závisí od toho, čo používateľ robí v tom čase. Ak čítate svoj e-mail počas spustenia, s najväčšou pravdepodobnosťou bude požiadavka na systémové prostriedky nízka a priebežná lišta sa bude posúvať dôsledne. Na druhej strane, ak robíte úpravu grafiky, potom bude vaša požiadavka na systémové zdroje oveľa väčšia, čo spôsobí, že pohybový posun bude schizofrenický.
Celkovo je jednoducho, že neexistuje krištáľová guľa. Ani samotný systém nevie, aké zaťaženie bude v budúcnosti kedykoľvek.
Nakoniec to naozaj nemá zmysel
Zámerom priebežného pruhu je jasne povedať, že je skutočne dosiahnutý pokrok a príslušný proces nie je zavesený. Je pekné, keď je ukazovateľ pokroku presný, ale zvyčajne je to len nepatrné nepríjemnosti, keď to nie je. Z väčšej časti vývojári nebudú venovať veľkú časť času a úsilia algoritmom pokrokových línií, pretože úprimne povedané, sú oveľa dôležitejšie úlohy, aby ste trávili čas.
Samozrejme, máte všetko právo byť naštvaný, keď sa pokrok dosiahne až na 99% okamžite a potom vás čaká 5 minút na zostávajúce jedno percento. Ak však príslušný program funguje celkovo, stačí pripomenúť, že vývojár mal svoje priority rovno.
