Proč jsou ty poklady tak nepřesné?

Na první pohled se zdá, že vytváření přesného odhadu času by mělo být poměrně snadné. Koneckonců, algoritmus, který produkuje ukazatel průběhu, zná všechny úkoly, které musí udělat před časem ... správně?

Z velké části je pravda, že zdrojový algoritmus ví, co musí předem udělat. Nicméně, stanovení času, který bude vyžadovat provedení každého kroku, je velmi obtížný, ne-li prakticky nemožný úkol.

Všechny úkoly nejsou vytvořeny rovnocenné

Nejjednodušší způsob implementace pruhu postupu je použití grafického znázornění čítače úloh. Kde je procento úplné jednoduše vypočteno jako Dokončené úkoly / Celkový počet úkolů. Zatímco to má logický smysl na první myšlenku, je důležité si uvědomit, že (samozřejmě) některé úkoly trvají déle.

Zvažte následující úlohy prováděné instalačním programem:

1. Vytvořte strukturu složek.
2. Dekomprimujte a zkopírujte soubory ve formátu 1 GB.
3. Vytvoření položek registru.
4. Vytvořte položky nabídky Start.

V tomto příkladu by kroky 1, 3 a 4 měly být dokončeny velmi rychle, zatímco krok 2 by trval nějakou dobu. Takže vývojový panel pracující na jednoduchém počítání by velmi rychle vyskočil na 25%, chvíli se zastavil, zatímco krok 2 funguje a pak skákal na 100% téměř okamžitě.

Tento typ implementace je ve skutečnosti poměrně častý mezi ukazateli pokroku, protože jak je uvedeno výše, je snadné jej implementovat. Nicméně, jak vidíte, je předmětem nepřiměřených úkolů aktuální procentuální pokrok, pokud jde o zbývající čas.

Chcete-li toto vyřešit, některé body postupu mohou používat implementace, kde jsou váhy váženy. Vezměte v úvahu výše uvedené kroky, kde je přiřazena relativní váha každému kroku:

1. Vytvořte strukturu složek. [Hmotnost = 1]
2. Dekomprimujte a zkopírujte soubory ve formátu 1 GB. [Hmotnost = 7]
3. Vytvoření položek registru. [Hmotnost = 1]
4. Vytvořte položky nabídky Start. [Hmotnost = 1]

Použitím této metody se průběžná lišta pohybuje v krocích po 10% (celková váha je 10), kroky 1, 3 a 4 pohybují tyč 10% po dokončení a krok 2 pohybuje se o 70%. Zatímco určitě není dokonalá, metody jako je tento jsou jednoduchý způsob, jak přidat procentuálně vyšší míru přesnosti.

Dosavadní výsledky nezaručují budoucí výkon

Uvažujme o jednoduchém příkladu, kdybych vás požádal o započítání na 50, zatímco používám stopky pro čas, který jste vy. Řekněme, že počítáte na 25 za 10 sekund. Bylo by rozumné předpokládat, že zbývající čísla počítáte za dalších 10 vteřin, takže průběžná čára, která bude sledovat tohle, bude ukazovat 50% dokončených a zbývajících 10 sekund.

Jakmile se váš počet dostane do 25 let, začnu házet tenisové míčky na vás. Je pravděpodobné, že se to váš rytmus zlomí, protože se vaše koncentrace přesunula od přísného započítávání čísel do vyhýbavých míčů, které vám způsobily cestu. Za předpokladu, že jste schopni pokračovat v počítání, vaše tempo jistě zpomalilo. Takže nyní se průběžný pruh stále pohybuje, ale s mnohem pomalejším tempem s předpokládaným časem, který zůstává buď v klidu, nebo ve skutečnosti vyšším.

Pro praktičtější příklad tohoto postupu zvažte stažení souboru. Aktuálně stahujete 100 MB soubor rychlostí 1 MB / s. To je velmi snadné určit odhadovaný čas dokončení. Ale 75% z toho způsobu, některé zásahy přetížení sítě a rychlost stahování klesne na 500 KB / s.

V závislosti na tom, jak prohlížeč vypočítá zbývající čas, vaše ETA může okamžitě přejít z 25 sekund na 50 sekund (pouze s použitím současného stavu: Zbývající velikost / Rychlost stahování) nebo s největší pravděpodobností prohlížeč používá algoritmus válečkového průměru, který by se přizpůsobil kolísání přenosové rychlosti bez zobrazení dramatických skoků k uživateli.

Příklad algoritmu pro stahování souborů může vypadat takto:

• Rychlost přenosu za posledních 60 sekund je zapamatována s nejnovější hodnotou nahrazující nejstarší (například 61. hodnota nahrazuje první).
• Účinná přenosová rychlost pro účely výpočtu je průměr těchto měření.
• Zbývající čas se vypočítá jako: Zbývající velikost / efektivní rychlost stahování

Použijte náš scénář výše (z důvodu jednoduchosti použijeme 1 MB = 1 000 KB):

• Po uplynutí 75 sekund do stahování by naše 60 vzpomínaných hodnot mělo mít hodnotu 1000 KB. Efektivní přenosová rychlost je 1000 kB (60 000 KB / 60), což znamená, že zbývá 25 sekund (25 000 KB / 1 000 KB).
• Po 76 sekundách (kde rychlost přenosu klesne na 500 KB) se efektivní rychlost stahování stává ~ 992 KB (59,500 KB / 60), což zbyde zbývajícího času ~ 24,7 sekund (24,500 KB / 992 KB).
• U 77 sekund: Efektivní rychlost = ~ 983 KB (59 000 KB / 60), což zbylo zbývajícího času ~ 24,4 sekund (24 000 KB / 983 KB).
• Po 78 sekundách: Efektivní rychlost = 975 KB (58,500 KB / 60), což zbylo zbývajícího času ~ 24,1 sekund (23,500 KB / 975 KB).

Zde vidíte vzorek, který se zde objevuje, poněvadž rychlost stahování je pomalu začleněna do průměru, který se používá k odhadnutí zbývajícího času. Při této metodě, pokud ponoření trvalo pouze 10 vteřin a pak se vrátilo na 1 MB / s, je pravděpodobné, že uživatel si nevšimne rozdíl (s výjimkou velmi malého stallu v předpokládaném odpočítávání času).

Dostanete se k mosazným páskům - jedná se jednoduše o metodologii pro předávání informací konečnému uživateli o skutečné základní příčině ...

Nemůžete přesně určit něco, co je nedeterministické

Nakonec se nepřesnost v oblasti pokroku snižuje na skutečnost, že se snaží určit čas pro něco, co je nedeterministická. Vzhledem k tomu, že počítače zpracovávají úkoly jak na požádání, tak na pozadí, je téměř nemožné zjistit, jaké systémové prostředky budou v budoucnosti k dispozici - a to je dostupnost systémových prostředků, které jsou potřebné pro dokončení všech úloh.

Pomocí jiného příkladu předpokládejme, že používáte aktualizaci programu na serveru, který provádí poměrně intenzivní aktualizaci databáze. Během tohoto procesu aktualizace uživatel odesílá náročný požadavek do jiné databáze spuštěné v tomto systému. Nyní musí serverové zdroje, konkrétně pro databázi, zpracovávat požadavky jak na upgrade, tak na dotaz spuštěný uživatelem - scénář, který bude jistě vzájemně škodlivý pro dobu provádění. Uživatel může alternativně iniciovat velký požadavek na přenos souborů, který by zdanil propustnost ukládání dat, která by také snížila výkon. Nebo by se mohla spustit naplánovaná úloha, která provádí proces náročný na paměť. Získáte ten nápad.

Jako možná realističtější instance pro běžného uživatele - zvažte spuštění služby Windows Update nebo antivirové kontroly. Obě tyto operace provádějí operace intenzivně na pozadí. Výsledkem toho je, že každý postup závisí na tom, co uživatel v daném okamžiku dělá. Pokud čtete svůj e-mail během běhu, pravděpodobně bude poptávka po systémových zdrojích nízká a průběžná čára se bude posunovat důsledně. Na druhou stranu, pokud děláte grafickou úpravu, pak bude vaše poptávka po systémových zdrojích mnohem větší, což způsobí, že pohybový posun bude být schizofrenní.

Celkově jde prostě o to, že není křišťálová koule. Dokonce ani samotný systém neví, jakou zátěž bude v budoucnu fungovat.

Nakonec to opravdu nemá záležitost

Záměrem pruhu o pokroku je samozřejmě ukázat, že skutečně probíhá pokrok a příslušný proces není zavěšen. Je pěkné, když je ukazatel pokroku přesný, ale obvykle je to jen nepatrná nepríjemnost, když tomu tak není. Z velké části se vývojáři nebudou věnovat velkou část času a úsilí algoritmům pokrokových barů, protože upřímně řečeno, jsou mnohem důležitější úkoly,.

Samozřejmě, máte všechno právo být otráveni, když průběžný pruh přeskočí na 99% okamžitě a pak vás čeká 5 minut na zbývající jedno procento. Pokud však příslušný program funguje dobře, připomeňte si, že vývojář měl své priority rovno.