Miért olyan pontatlanok a Progress Barok?

Első gondolat szerint úgy tűnik, hogy az idő pontos becslése meglehetősen egyszerű. Végül is, az előrehaladási sávot előállító algoritmus mindazokat a feladatokat ismeri, amelyeket az idő előtt meg kell tennie?

A legtöbb esetben igaz, hogy a forrás algoritmus tudja, mit kell tennie az idő előtt. Azonban az egyes lépések végrehajtásához szükséges idő lerövidítése nagyon nehéz, ha nem gyakorlatilag lehetetlen feladat.

Az összes feladat nem egyenlő

Az előrehaladási sáv végrehajtásának legegyszerűbb módja a feladatszámláló grafikus ábrázolása. Ha a teljes százalékot egyszerűen kiszámítjuk, akkor a Befejezett feladatok / a feladatok teljes száma. Bár ez logikus értelme van az első gondolatnak, fontos megjegyezni, hogy (nyilvánvalóan) néhány feladat hosszabb időt vesz igénybe.

Fontolja meg a telepítő által végzett következő feladatokat:

1. Mappaszerkezet létrehozása.
2. Dekompresszi és másolja 1 GB értékű fájlt.
3. Regisztrációs bejegyzések létrehozása.
4. Start menübejegyzések létrehozása.

Ebben a példában az 1., 3. és 4. lépés nagyon gyorsan befejeződik, míg a 2. lépés egy kis időt vesz igénybe. Tehát egy egyszerű számlán működő előrehaladási sáv nagyon gyorsan 25% -ra ugrik, egy kicsit elakad, míg a 2. lépés működik, majd majdnem azonnal 100% -ra ugrik.

Ez a fajta megvalósítás valóban meglehetősen gyakori a progresszív sávok között, mert - amint azt a fentiekben említettük - könnyen megvalósítható. Azonban, ahogy láthatjuk, az aránytalan feladatoknak vannak kitéve, amelyek a tényleges a hátralévő időre vonatkozó előrehaladási százalék.

Ennek érdekében bizonyos előrehaladási sávok olyan lépéseket használhatnak, ahol a lépéseket súlyozzák. Tekintse meg a fenti lépéseket, ahol az egyes lépésekhez relatív súlyt rendelnek:

1. Mappaszerkezet létrehozása. [Súly = 1]
2. Dekompresszi és másolja 1 GB értékű fájlt. [Súly = 7]
3. Regisztrációs bejegyzések létrehozása. [Súly = 1]
4. Start menübejegyzések létrehozása. [Súly = 1]

Ezzel a módszerrel az előrehaladási sáv 10% -os lépésekben mozog (az össztömeg 10), az 1., 3. és 4. lépéssel a 10% -os sávot a befejezés után mozgatja, és a 2. lépést 70% -kal mozgatja. Bár biztosan nem tökéletes, az ilyen módszerek egy egyszerű módja annak, hogy egy kicsit több pontosságot adjunk a haladási sáv százalékos arányához.

A korábbi eredmények nem garantálják a jövőbeni teljesítményt

Vegyünk egy egyszerű példát arra, hogy számítsunk 50-re, miközben stopperórát használok. Tegyük fel, hogy 10 másodperc alatt 25-re számít. Indokolt lenne feltételezni, hogy további 10 másodpercen belül megszámolja a fennmaradó számokat, így egy előrehaladási sáv nyomon követése 50% -kal teljesülne 10 másodperc alatt.

Amint a gróf eléri a 25-et, elkezdem dobni a teniszlabdákat. Valószínűleg ez megszakítja a ritmust, mivel a koncentráció a szigorúan számláló számoktól az útra dobott golyókig terjed. Feltételezve, hogy képesek vagyunk a számlálás folytatására, a tempóod egy kicsit lassult. Tehát most a haladási sáv még mindig mozog, de sokkal lassabb ütemben, a becsült idő, amely vagy megállt, vagy ténylegesen magasabbra emelkedik.

Ennek gyakorlati példája érdekében fontolja meg egy fájl letöltését. Jelenleg 1 MB / s sebességgel letölti a 100 MB-os fájlt. Ez nagyon könnyű meghatározni a becsült befejezési időt. De az út 75% -a, néhány hálózati torlódás megüt, és a letöltési aránya 500 KB / s-ra csökken.

Attól függően, hogy a böngésző hogyan számítja ki a hátralévő időt, az ETA azonnal 25 másodpercről 50 másodpercre mehet (csak a jelenlegi állapotban: Megmaradó méret / letöltési sebesség) vagy valószínűleg a böngésző egy gördülő átlag algoritmust használ, amely az átviteli sebesség ingadozásához igazodik anélkül, hogy drámai ugrásokat mutatna a felhasználónak.

A gördülő algoritmus egy példája egy fájl letöltésére vonatkozóan ilyesmi lehet:

• Az előző 60 másodpercre vonatkozó átviteli sebességet a legrégebbi értékkel rendelkező legújabb értékkel (például az első helyettesítő 61-es értékkel) kell emlékezni..
• A számításhoz szükséges tényleges átviteli sebesség a mérések átlaga.
• A hátralévő idő: Megmaradó méret / hatékony letöltési sebesség

Tehát a fenti forgatókönyvünk segítségével (az egyszerűség kedvéért 1 MB = 1 000 KB-ot használunk):

• A letöltés 75 másodpercében 60 emlékezett értékünk 1000 KB lesz. A tényleges átvitel aránya 1000 KB (60 000 KB / 60), ami 25 másodpercig tart (25 000 KB / 1000 KB).
• 76 másodpercen belül (ahol az átviteli sebesség 500 KB-ra csökken) a tényleges letöltési sebesség ~ 992 KB (59,5 KB / 60) lesz, ami ~ 24,7 másodpercig marad (24,5 KB / 992 KB).
• 77 másodpercen belül: effektív sebesség = ~ 983 KB (59 000 KB / 60) ~ 24,4 másodperc marad (24 000 KB / 983 KB).
• 78 másodpercen keresztül: effektív sebesség = 975 KB (58,500 KB / 60) ~ 24,1 másodperc marad (23,500 KB / 975 KB).

Láthatjuk az itt megjelenő mintát, mivel a letöltési sebesség csökkenése lassan bekerül az átlagba, amelyet a hátralévő idő becsléséhez használnak. Ezzel a módszerrel, ha a dip csak 10 másodpercig tartott, majd visszaállt 1 MB / s-ra, a felhasználó valószínűleg nem fogja észrevenni a különbséget (kivéve a becsült idő visszaszámlálásban egy nagyon kisebb bukást).

A sárgarézcsapokhoz való hozzáférés - ez egyszerűen módszertan arra, hogy a végfelhasználónak átadja az információt a tényleges alapkérdésekről…

Nem lehet pontosan meghatározni valamit, ami nem meghatározó

Végső soron az előrehaladási sáv pontatlansága arra a tényre támaszkodik, hogy megpróbálja meghatározni az időt egy olyan dologra, amely nem meghatározó. Mivel a számítógépek mind a keresleten, mind a háttérben futó feladatokat dolgoznak fel, szinte lehetetlen tudni, hogy a rendszer milyen erőforrások állnak rendelkezésre a jövőben - és a rendszer erőforrásainak rendelkezésre állása szükséges ahhoz, hogy bármilyen feladat elvégezhető legyen.

Egy másik példa segítségével feltételezzük, hogy egy programfrissítést futtat egy olyan kiszolgálón, amely meglehetősen intenzív adatbázis-frissítést hajt végre. A frissítési folyamat során a felhasználó egy igényes kérelmet küld egy másik, a rendszeren futó adatbázishoz. A szerver erőforrásoknak, különösen az adatbázisnak, mind a frissítésre, mind a felhasználó által kezdeményezett lekérdezésre vonatkozó kéréseket kell feldolgozniuk - olyan forgatókönyv, amely minden bizonnyal kölcsönösen káros lesz a végrehajtási időre. Másik megoldásként a felhasználó kezdeményezhet egy nagy fájlátviteli kérést, amely adóztatná a tárolási teljesítményt, ami csökkentené a teljesítményt is. Vagy egy ütemezett feladat elindíthatja a memóriát intenzív folyamatot. Megkapja az ötletet.

Mint talán egy mindennaposabb felhasználó számára reálisabb eset - fontolja meg a Windows Update vagy a víruskeresést. Mindkét művelet erőforrásigényes műveleteket hajt végre a háttérben. Ennek eredményeképpen az egyes gyártmányok előrehaladása attól függ, hogy a felhasználó milyen időben dolgozik. Ha e-mailjét olvassa, miközben ez fut, valószínűleg a rendszer erőforrásainak igénye alacsony lesz, és a folyamatjelző sáv következetesen mozog. Másrészt, ha grafikus szerkesztést végez, akkor a rendszer erőforrásai iránti igénye sokkal nagyobb lesz, ami az előrehaladási sáv mozgását skizofréné teszi..

Összességében egyszerűen az, hogy nincs kristálygömb. Még a rendszer sem tudja, hogy milyen terhelés lesz a jövőben.

Végső soron valóban nem számít

Az előrehaladási sáv célja, hogy jól jelezze, hogy valóban előrehaladást értünk el, és az adott folyamat nem lóg. Jó, ha az előrehaladás mutatója pontos, de tipikusan csak kisebb bosszúság, ha nem. A fejlesztők nagyrészt nem fognak sok időt és erőfeszítést fordítani az előrehaladási sáv algoritmusaira, mert őszintén szólva, sokkal fontosabb feladatok vannak az időtöltésre.

Természetesen minden joga van, hogy bosszantja, ha egy előrehaladási sáv azonnal 99% -ra ugrik, majd 5 percet vár a fennmaradó egy százalékra. De ha az adott program általánosan működik, csak emlékeztessük magunkat arra, hogy a fejlesztőnek egyenesen prioritása van.