A legtöbb esetben igaz, hogy a forrás algoritmus tudja, hogy mit kell tenni az idő előtt. Azonban az egyes lépések elvégzéséhez szükséges idő eltörlése nagyon nehéz, ha nem gyakorlatilag lehetetlen feladat.
Az összes feladat nem egyenlő
A folyamatjelző legegyszerűbb módja a feladatszámláló grafikus megjelenítése. Ahol a teljes százalékot egyszerűen számítják Befejezett feladatok / feladatok teljes száma. Bár ez logikus értelemben van az első gondolatnál, fontos megjegyezni, hogy (természetesen) egyes feladatok hosszabb ideig tartanak.
Vegye figyelembe a következő feladatokat:
- Készítsen hozzá mappa szerkezetét.
- Dekompressz és másolja 1 GB értékű fájlokat.
- Regisztrációs bejegyzések létrehozása.
- Indítsa el a menüpontokat.
Ebben a példában az 1., 3. és 4. lépések nagyon gyorsan befejeződnének, míg a 2. lépés időbe telik. Tehát egy egyszerű számláláson végzett előrehaladási sáv nagyon gyorsan ugrott a 25% -ra, egy kicsit leállt, míg a 2. lépés működik, majd majdnem azonnal ugorjon 100% -ra.
Az ilyen típusú megvalósítás valójában meglehetősen gyakori az előrehaladási rudak között, mert - amint azt fent említettük - könnyen megvalósítható. Azonban, ahogy láthatja, aránytalanul nagy feladatokat ellensúlyoz tényleges az előrehaladás százalékát, mivel a hátralévő időre vonatkozik.
Ennek meggondolásához egyes előrehaladási sávok olyan implementációkat használhatnak, ahol a lépéseket súlyozzák. Tekintsük át a fenti lépéseket, ahol relatív súlyt rendelünk minden lépéshez:
- Készítsen hozzá mappa szerkezetét. [Súly = 1]
- Dekompressz és másolja 1 GB értékű fájlokat. [Súly = 7]
- Regisztrációs bejegyzések létrehozása. [Súly = 1]
- Indítsa el a menüpontokat. [Súly = 1]
Ezzel a módszerrel az előrehaladási sáv 10% -os lépésekben mozogni kezd (az összsúly 10), az 1., 3. és 4. lépésekkel a sáv 10% -át a befejezés után mozgatja, a második lépés pedig 70% -ot mozgat. Bár biztosan nem tökéletes, az ilyen módszerek egy egyszerű módja annak, hogy egy kicsit nagyobb pontosságot adjunk az előrehaladási ponthoz.
A korábbi eredmények nem garantálják a jövőbeni teljesítményt
Miután a számod eléri a 25-öt, elkezdem teniszlabdákat dobni rád. Valószínűleg ez megszakítja a ritmust, mivel koncentrációja a szigorúan számláló számoktól kezdve elhomályosította a labdákat. Feltéve, hogy folytathatja a számlálást, üteme biztosan lelassult. Tehát most az előrehaladási sáv még mindig mozog, de sokkal lassabb ütemben, ha a becsült idő vagy stagnál, vagy tényleg magasabbra emelkedik.
Ha gyakorlatiasabb példát szeretne, fontolja meg a fájl letöltését. Jelenleg 100 MB-os fájlt tölt le 1 MB / s sebességgel. Ez nagyon könnyű meghatározni a becsült befejezési időt. Azonban az út 75% -a, néhány hálózati torlódás, és letöltési sebessége 500 KB / s-ra csökken.
Attól függően, hogy a böngésző kiszámítja a hátralévő időt, az ETA azonnal 25 másodpercről 50 másodpercre megy (csak a jelenlegi állapotot használva: Méretmaradó / letöltési sebesség), vagy valószínűleg a böngésző egy gördülõ átlagos algoritmust használ, amely az átviteli sebesség ingadozásait alkalmazza anélkül, hogy drámai ugrik a felhasználó felé.
A fájl letöltésére vonatkozó gördülő algoritmus például egy ilyen módon működhet:
- Az elmúlt 60 másodperces átviteli sebességet a legrégebbi (leggyakrabban a 61. helyettesítő) helyettesítő legfrissebb értéke figyelembevételével jegyzi meg.
- A tényleges átviteli sebesség a számítás céljára a mérések átlaga.
- A hátralévő idő kiszámítása: Hátralévő / Hatékony letöltési sebesség
Tehát a fenti forgatókönyv használatával (az egyszerűség kedvéért 1 MB = 1000 KB-t használunk):
- A letöltés 75 másodpercig 60 emlékezett értékünk 1000 KB. A tényleges átviteli sebesség 1000 KB (60.000 KB / 60), ami 25 másodperces maradt (25.000 KB / 1000 KB).
- 76 másodperc múlva (ahol az átviteli sebesség 500 kB-ra csökken) a tényleges letöltési sebesség ~ 992 kB (59 500 kB / 60) lesz, ami ~ 24,7 másodperc (24 500 KB / 992 kB) maradt.
- 77 másodpercen belül: tényleges sebesség = ~ 983 KB (59 000 KB / 60), így a hátralévő idő ~ 24,4 másodperc (24 000 KB / 983 KB) maradt.
- 78 másodperc alatt: A tényleges sebesség = 975 KB (58 500 KB / 60), így a hátralévő idő ~ 24,1 másodperc (23,500 KB / 975 KB).
Láthatja a megjelenő mintát, amikor a letöltési sebesség csökkenése lassan beilleszkedik az átlagba, amely a hátralévő idő becslésére szolgál. Ebben a módszerben, ha a merülés csak 10 másodpercig tartott, majd 1 MB / s-ra visszatért, a felhasználó nem fogja észrevenni a különbséget (a becsült idő visszaszámlálásnál csak egy nagyon kicsi stall).
A rézfúvókhoz való hozzáférés - ez egyszerűen a végfelhasználó számára történő információ továbbításának módszertana az aktuális okok miatt …
Nem tudsz pontosan meghatározni valamit, ami nem-meghatározó
Végül, az előrehaladási sáv pontatlansága lefagy arra a tényre, hogy megpróbál meghatározni egy olyan időpontot, ami nem meghatározó. Mivel a számítógépek számítógépes feladatokat igényelnek és igénylik a háttérben, szinte lehetetlen megmondani, hogy a jövőben bármelyik rendszer erőforrása elérhető lesz - és a rendszer erőforrásainak rendelkezésre állása szükséges minden feladat elvégzéséhez.
Ha egy másik példát használ, tegyél fel egy olyan programfrissítést, amely meglehetősen intenzív adatbázisfrissítést végez. A frissítés folyamán a felhasználó egy igényes kérést küld a rendszeren futó másik adatbázisnak. Most a kiszolgálói erőforrások, különös tekintettel az adatbázisra, feldolgozniuk kell mind a frissítést, mind pedig a felhasználó által kezdeményezett lekérdezést - olyan forgatókönyv, amely mindenképpen hátrányosan befolyásolja a végrehajtási időt. Alternatív megoldásként a felhasználó egy nagy fájlátviteli kérelmet kezdeményezhet, amely adóztatná a tárolási kapacitást, ami hátrányosan befolyásolná a teljesítményt is. Vagy egy ütemezett feladat elindulhat, amely memóriaintenzív folyamatot hajt végre. Megvan az ötlet.
Mint talán egy reálisabb példány egy mindennapi felhasználó számára - fontolja meg a Windows Update futtatását vagy a víruskeresést. Mindkét művelet a háttérben erőforrás-intenzív műveleteket végez. Ennek eredményeként az előrehaladás attól függ, hogy mit csinál a felhasználó az adott időben. Ha e-maileket olvas, amíg ez fut, valószínűleg alacsony a rendszererőforrás iránti kereslet, és az előrehaladási sáv következetesen mozog. Másrészt, ha grafikus szerkesztést végez, akkor a rendszer erőforrások iránti igénye sokkal nagyobb lesz, ami az előrehaladási sáv mozgását skizofrén hatásúvá teszi.
Összességében egyszerűen nincs kristálygömb. Még a rendszer sem tudja, hogy milyen terhelés alatt lesz a jövő bármely pontján.
Végül is tényleg nem számít
Az előrehaladási sáv szándéka az, hogy jól mutatja, hogy a haladás valóban megtörténik, és az adott folyamat nem függ. Jó, ha az előrehaladási mutató pontos, de általában csak egy kis bosszúság, ha nem. A fejlesztők többnyire nem fognak sok időt és energiát fordítani a folyamatjelző algoritmusokra, mert őszintén szólva sokkal fontosabb feladatokat kell tölteni.
Természetesen mindenkinek joga van bosszantani, ha egy előrehaladási sáv azonnal 99% -ra ugrik, és akkor 5 percet vár a fennmaradó 1 százalékra. De ha a megfelelő program jól működik, csak emlékeztesse magát, hogy a fejlesztőnek egyenrangúak voltak a prioritásaik.
