De ce sunt barele de progres atât de inexacte?

La început, se pare că generarea unei estimări precise a timpului ar trebui să fie destul de ușoară. La urma urmei, algoritmul care produce bara de progres cunoaște toate sarcinile pe care trebuie să le îndeplinească înainte ... corect?

În cea mai mare parte, este adevărat că algoritmul sursă nu știe ce trebuie să facă înainte. Cu toate acestea, fixarea timpului necesar pentru a efectua fiecare pas este o sarcină foarte dificilă, dacă nu chiar imposibilă.

Toate sarcinile nu sunt create egale

Cea mai simplă modalitate de a implementa o bară de progres este de a folosi o reprezentare grafică a contorului de sarcini. În cazul în care procentul complet este pur și simplu calculat ca Sarcini completate / numărul total de sarcini. În timp ce acest lucru are sens logic la primul gând, este important să ne amintim că (în mod evident) anumite sarcini necesită mai mult timp pentru a finaliza.

Luați în considerare următoarele activități efectuate de un instalator:

1. Creați structura folderului.
2. Decomprimați și copiați fișiere în valoare de 1 GB.
3. Creați intrări de registry.
4. Creați intrări din meniul de pornire.

În acest exemplu, pașii 1, 3 și 4 s-ar termina foarte repede, în timp ce pasul 2 va dura ceva timp. Deci, un bar de progres care lucrează la un număr simplu ar urca foarte repede la 25%, se va stoarce puțin în timp ce pasul 2 va funcționa și apoi va sari la 100% aproape imediat.

Acest tip de implementare este de fapt destul de comun printre barele de progres, deoarece, așa cum sa menționat mai sus, este ușor de implementat. Cu toate acestea, după cum puteți vedea, este supusă unor sarcini disproporționate real Procentul de progres care se referă la timpul rămas.

Pentru a rezolva această problemă, unele bare de progres pot utiliza implementări în cazul cărora pașii sunt ponderați. Luați în considerare pașii de mai sus în cazul în care o greutate relativă este atribuită fiecărei etape:

1. Creați structura folderului. [Greutate = 1]
2. Decomprimați și copiați fișiere în valoare de 1 GB. [Greutate = 7]
3. Creați intrări de registry. [Greutate = 1]
4. Creați intrări din meniul de pornire. [Greutate = 1]

Folosind această metodă, bara de progres s-ar mișca în trepte de 10% (greutatea totală este de 10), etapele 1, 3 și 4 mutând bara 10% la finalizare și pasul 2 deplasându-l cu 70%. În timp ce cu siguranță nu este perfect, metode precum aceasta sunt o modalitate simplă de a adăuga un pic mai multă precizie la procentul barei de progres.

Rezultatele anterioare nu garantează performanța viitoare

Luați în considerare un exemplu simplu de a vă cere să numărați până la 50 de ani în timp ce folosesc un cronometru pentru a vă prezenta. Să presupunem că numărați la 25 în 10 secunde. Ar fi rezonabil să presupunem că veți număra restul de numere în încă 10 secunde, astfel că o bară de progres care o urmărește ar arăta 50% completă, cu 10 secunde rămase.

Odată ce numărul dvs. ajunge la 25, totuși, încep să arunc mingi de tenis la tine. Probabil, acest lucru vă va rupe ritmul, pe măsură ce concentrarea dvs. sa mutat de la numărarea cu strictețe a numerelor la bilele de evadare aruncate în cale. Presupunând că puteți continua să numărați, ritmul dvs. a încetinit puțin. Deci acum bara de progres se mișcă încă, dar într-un ritm mult mai lent, cu timpul estimat rămânând fie în staționare, fie chiar alpinist mai înalt.

Pentru un exemplu mai practic, luați în considerare descărcarea unui fișier. În prezent, descărcați un fișier de 100 MB la o rată de 1 MB / s. Este foarte ușor să determinați timpul estimat de finalizare. Însă 75% din acest mod, unele hit-uri de congestie a rețelei și rata descărcării scade la 500 KB / s.

În funcție de modul în care browserul calculează timpul rămas, ETA ar putea trece instantaneu de la 25 de secunde la 50 de secunde (folosind numai starea actuală: Dimensiunea rămasă / viteza de descărcare) sau, cel mai probabil, browserul folosește un algoritm mediu de rulare care se va ajusta pentru fluctuațiile vitezei de transfer fără a afișa salturi dramatice către utilizator.

Un exemplu de algoritm de rulare cu privire la descărcarea unui fișier ar putea funcționa astfel:

• Viteza de transfer pentru precedentele 60 de secunde este reținută cu cea mai recentă valoare care înlocuiește cea mai veche (de exemplu, cea de-a 61-a valoare înlocuiește prima).
• Rata efectivă de transfer în scopul calculării este media acestor măsurători.
• Timpul rămas este calculat astfel: Dimensiunea rămasă / eficienta viteza de download

Deci, folosind scenariul de mai sus (de dragul simplității, vom folosi 1 MB = 1.000 KB):

• La 75 de secunde în descărcare, cele 60 de valori amintite ar fi fiecare 1000 KB. Rata de transfer efectivă este de 1.000 KB (60.000 KB / 60), ceea ce are un timp de 25 de secunde (25.000 KB / 1.000 KB).
• La 76 de secunde (viteza de transfer scade la 500 KB), viteza efectivă de descărcare devine ~ 992 KB (59,500 KB / 60), ceea ce are un timp rezidual de ~ 24,7 secunde (24,500 KB / 992 KB).
• La 77 de secunde: Viteza efectivă = ~ 983 KB (59.000 KB / 60), ceea ce înseamnă că timpul rămas de ~ 24.4 secunde (24.000 KB / 983 KB).
• La 78 de secunde: Viteză efectivă = 975 KB (58,500 KB / 60), cu un timp de așteptare de aproximativ 24,1 secunde (23,500 KB / 975 KB).

Puteți vedea modelul care apare aici, deoarece scăderea vitezei de descărcare este încet încorporată în media care este utilizată pentru a estima timpul rămas. Sub această metodă, în cazul în care dip-ul a durat doar 10 secunde și apoi a revenit la 1 MB / s, este puțin probabil ca utilizatorul să observe diferența (cu excepția unui stand foarte mic în timpul de așteptare estimat).

Noțiuni de bază la aripi de alamă - aceasta este pur și simplu metodologia pentru transmiterea de informații pentru utilizatorul final pentru cauză reală de bază ...

Nu puteți determina cu exactitate ceva care este nedeterministă

În cele din urmă, inexactitatea bara de progres se reduce la faptul că încearcă să determine timpul pentru ceva care nu este determinist. Deoarece computerele procesează sarcini atât la cerere, cât și în fundal, este aproape imposibil să știți ce resurse de sistem vor fi disponibile în orice moment în viitor - și este disponibilitatea resurselor de sistem necesare pentru îndeplinirea oricărei sarcini.

Folosind un alt exemplu, să presupunem că executați o actualizare de program pe un server care efectuează o actualizare destul de intensă a bazei de date. În timpul acestui proces de actualizare, un utilizator trimite apoi o solicitare exigentă unei alte baze de date care rulează pe acest sistem. Acum, resursele serverului, în special pentru baza de date, trebuie să proceseze cereri atât pentru actualizarea dvs., cât și pentru interogarea inițiată de utilizator - un scenariu care va fi cu siguranță un efect negativ asupra duratei de execuție. Alternativ, un utilizator ar putea iniția o cerere mare de transfer de fișiere, care să impoziteze capacitatea de stocare care ar afecta performanța. Sau ar putea începe o sarcină programată, care realizează un proces intensiv de memorie. Ai idee.

Ca, probabil, o instanță mai realistă pentru un utilizator de zi cu zi - luați în considerare rularea Windows Update sau scanarea de virusi. Ambele operațiuni efectuează operații intensive în fundal. Ca rezultat, progresele realizate de fiecare depinde de ceea ce face utilizatorul în acel moment. Dacă citiți e-mailurile în timp ce acestea rulează, probabil că cererea de resurse de sistem va fi scăzută și bara de progres va fi mutată în mod consecvent. Pe de altă parte, dacă faceți editare grafică, atunci cererea dvs. privind resursele de sistem va fi mult mai mare, ceea ce va determina mișcarea bara de progres să fie schizofrenică.

În general, este pur și simplu că nu există nici o minge de cristal. Nici sistemul în sine nu știe ce încărcare va fi în orice moment în viitor.

În cele din urmă, chiar nu are importanță

Scopul barei de progres este de a indica, bineînțeles, că se înregistrează progrese și că procesul respectiv nu este atins. Este drăguț atunci când indicatorul de progres este corect, dar de obicei este doar o mică neplăcere atunci când nu este. În cea mai mare parte, dezvoltatorii nu vor dedica prea mult timp și efort în algoritmii de progresie, deoarece, sincer, există mult mai importante sarcini pentru a petrece timp.

Desigur, aveți toate dreptul de a fi supărat când un bara de progres sare până la 99% completă instantaneu și apoi vă face să așteptați 5 minute pentru restul de 1%. Dar dacă programul respectiv funcționează bine în ansamblul său, trebuie doar să vă reamintiți că dezvoltatorul are prioritățile prioritare.