Prečo sú priebežné bary tak nepresné?

Na prvý pohľad sa zdá, že vytváranie presného odhadu času by malo byť pomerne jednoduché. Koniec koncov, algoritmus, ktorý produkuje ukazovateľ postupu, vie všetky úlohy, ktoré musí urobiť pred časom ... správne?

Z väčšej časti je pravda, že zdrojový algoritmus vie, čo musí urobiť pred časom. Stanovenie času, ktorý bude potrebné vykonať v každom kroku, je však veľmi zložitá, ak nie úplne nemožná.

Všetky úlohy nie sú vytvorené rovnaké

Najjednoduchší spôsob implementácie pruhu postupu je použiť grafické znázornenie počítadla úloh. Kde percento úplné je 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:

1. Vytvorte štruktúru priečinkov.
2. Dekomprimujte a kopírujte 1 GB súborov.
3. Vytvorte položky databázy Registry.
4. Vytvorte položky štartovnej ponuky.

V tomto príklade sa kroky 1, 3 a 4 dokončia veľmi rýchlo, kým krok 2 trvá určitý čas. Takže pokrok, ktorý pracuje na jednoduchom počte, by veľmi rýchlo vyskočil na 25%, chvíľu stoja, zatiaľ čo krok 2 funguje a potom skok na 100% takmer okamžite.

Tento typ implementácie je vlastne pomerne častý medzi ukazovateľmi 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 to chcete 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 sa priradí relatívna váha každému kroku:

1. Vytvorte štruktúru priečinkov. [Hmotnosť = 1]
2. Dekomprimujte a kopírujte 1 GB súborov. [Hmotnosť = 7]
3. Vytvorte položky databázy Registry. [Hmotnosť = 1]
4. 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ú lištou o 10% po dokončení a krok 2 sa pohybuje o 70%. Kým určite nie sú 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 na čas vás použijem stopky. Povedzme, že počítate na 25 za 10 sekúnd. Bolo by rozumné predpokladať, že zostávajúce čísla budú spočítané za ďalších 10 sekúnd, takže sledovanie priebehu tohto ukazovateľa by mohlo ukázať, že 50% je kompletné s 10 sekundami zostávajúcich.

Keď dosiahnete počet 25, začnem vám hádzať tenisové loptičky. Je pravdepodobné, že to prelomí váš rytmus, pretože vaša koncentrácia sa presunula zo striktného počítania čísel na uhýbanie guľôčky, ktoré vás hodili. Za predpokladu, že ste schopní pokračovať v započítaní, vaše tempo sa určite spomalilo. Teraz sa priebežný panel stále pohybuje, ale oveľa pomalšie, pričom predpokladaný čas zostáva buď zastavený, alebo skutočne stúpa vyššie.

Pre praktickejší príklad zvážte prevzatie 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 môže okamžite prejsť z 25 sekúnd na 50 sekúnd (iba v súčasnom stave: Zostávajúca veľkosť / rýchlosť sťahovania), alebo s najväčšou pravdepodobnosťou prehliadač používa algoritmus valcového priemeru, ktorý by sa prispôsobil kolísaniu prenosovej rýchlosti bez zobrazenia dramatických skokov k užívateľovi.

Príklad algoritmu o prevzatí súboru môže fungovať takto:

• Rýchlosť prenosu za posledných 60 sekúnd sa zapamätá s najnovšou hodnotou, ktorá nahradí najstaršiu (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 byť 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 prenosová rýchlosť 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 zvyšuje čas ~ 24,4 sekúnd (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 sa pomaly začlení 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átil 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čnú základnú príčinu ...

Nemôžete presne určiť niečo, čo je nedeterministické

Nakoniec, nepresnosť v pokrokovom stĺpci sa zhoršuje tým, že sa snaží určiť čas na niečo, čo je nedeterministické. Keďže počítače spracúvajú úlohy na požiadanie aj 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 prostriedkov, 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 vykonania. 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 náročný na pamäť. 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 behu, s najväčšou pravdepodobnosťou bude požiadavka na systémové zdroje nízka a priebežná lišta sa bude posúvať dôsledne. Na druhej strane, ak robíte editáciu grafiky, potom bude vaša požiadavka na systémové zdroje oveľa väčšia, čo spôsobí, že pohybový posun bude byť 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ľa času a úsilia algoritmom pokrokových barov, pretože úprimne povedané, je oveľa dôležitejšie, aby ste trávili čas.

Samozrejme, máte všetko právo byť obťažovaný, keď sa pokrok dosiahne na úrovni 99%, a okamžite počkajte 5 minút na zostávajúce jedno percento. Ak však príslušný program funguje celkom dobre, stačí pripomenúť, že vývojár mal svoje priority rovno.