Зашто су траке напретка тако нетачне?

На први поглед, чини се да би генерисање тачне процене времена требало да буде прилично лако. На крају крајева, алгоритам који ствара траку напретка познаје све задатке које треба обавити пре времена… тачно?

За већи део, тачно је да изворни алгоритам зна шта треба да уради унапред. Међутим, скривање времена које је потребно за извођење сваког корака је веома тежак, ако не и готово немогућ задатак.

Сви задаци нису једнаки

Најједноставнији начин да се имплементира трака напретка је да се користи графички приказ бројача задатака. Тамо где је проценат завршен једноставно израчунат као Завршени задаци / укупан број задатака. Иако ово на први поглед чини логичан смисао, важно је запамтити да (очигледно) за неке задатке треба више времена.

Размотрите следеће задатке које изводи инсталатер:

1. Креирајте структуру фолдера.
2. Декомпримирајте и копирајте датотеке од 1 ГБ.
3. Креирајте ставке регистра.
4. Креирајте ставке старт менија.

У овом примеру, кораци 1, 3 и 4 ће се завршити веома брзо, док ће корак 2 потрајати неко време. Дакле, трака напретка која ради на једноставном рачунању би скочила на 25% врло брзо, зауставила се мало док је корак 2 радио, а затим скочио на 100% готово одмах.

Овај тип имплементације је уствари прилично уобичајен код напредних трака јер је, као што је горе наведено, лако имплементирати. Међутим, као што можете видјети, то је подложно несразмјерним задацима који искривљују стварна постотак напретка који се односи на преостало вријеме.

Да бисте заобишли ово, неке траке напретка могу користити имплементације у којима су кораци пондерисани. Размотрите горе наведене кораке где је релативна тежина додељена сваком кораку:

1. Креирајте структуру фолдера. [Тежина = 1]
2. Декомпримирајте и копирајте датотеке од 1 ГБ. [Веигхт = 7]
3. Креирајте ставке регистра. [Тежина = 1]
4. Креирајте ставке старт менија. [Тежина = 1]

Користећи ову методу, трака напретка би се кретала у корацима од 10% (пошто је укупна тежина 10) са корацима 1, 3 и 4 померањем шипке 10% по завршетку и кораком 2 померањем 70%. Иако свакако нису савршени, методе као што је овај су једноставан начин да додате мало већу прецизност у проценат прогреса.

Претходни резултати не гарантују будуће перформансе

Размислите о једноставном примјеру да од вас тражим да бројите до 50 док користим штоперицу да вас проверим. Рецимо да бројите до 25 за 10 секунди. Било би разумно претпоставити да ћете бројати преостале бројеве за додатних 10 секунди, тако да ће праћење траке напретка показати 50% завршетка са преосталих 10 секунди.

Међутим, када број рачуна достигне 25, почињем бацати тениске лоптице на вас. Вероватно ће ово прекинути ваш ритам док је ваша концентрација прешла са стриктно бројања бројева на избегавање лоптица које вам бацају пут. Под претпоставком да сте у стању да наставите са бројањем, ваш ритам је сигурно мало успорио. Дакле, напредак је још увијек у покрету, али много спорије, док процијењено вријеме остаје или у застоју или се заправо успиње..

За практичнији пример тога, размотрите преузимање датотеке. Тренутно преузимате датотеку од 100 МБ брзином од 1 МБ / с. Ово је врло лако одредити процијењено вријеме завршетка. Али 75% пута до тамо, неке мреже загушења погоди и ваш довнлоад стопа пада до 500 КБ / с.

У зависности од тога како претраживач израчунава преостало време, ваша ЕТА може одмах да иде од 25 секунди до 50 секунди (користећи само тренутно стање: Сизе Ремаининг / Довнлоад Спеед) или, највјероватније, претраживач користи алгоритам котрљајућег просјека који ће се прилагодити за флуктуације брзине пријеноса без приказивања драматичних скокова кориснику.

Пример алгоритма за котрљање у вези са преузимањем датотеке може да ради нешто овако:

• Брзина преноса за претходних 60 секунди памти се са најновијом вредношћу која замењује најстарију (нпр. 61. вредност замењује прву).
• Ефективна стопа преноса у сврху израчунавања је просјек ових мјерења.
• Преостало време се рачуна као: Сизе Ремаининг / Ефективна брзина преузимања

Дакле, користећи наш сценарио горе (ради једноставности користићемо 1 МБ = 1.000 КБ):

• За 75 секунди преузимања, свака од 60 запамћених вриједности била би 1000 КБ. Ефективна стопа преноса је 1.000 КБ (60.000 КБ / 60) што даје преостало време од 25 секунди (25.000 КБ / 1,000 КБ).
• Са 76 секунди (где брзина преноса пада на 500 КБ), ефективна брзина преузимања постаје ~ 992 КБ (59,500 КБ / 60) што даје преостало време од ~ 24,7 секунди (24,500 КБ / 992 КБ).
• Са 77 секунди: Ефективна брзина = ~ 983 КБ (59,000 КБ / 60), време преостало од ~ 24,4 секунди (24,000 КБ / 983 КБ).
• За 78 секунди: Ефективна брзина = 975 КБ (58,500 КБ / 60) што даје преостало време од ~ 24,1 секунди (23,500 КБ / 975 КБ).

Можете видети да се образац појављује овде када се дип у брзини преузимања полако угради у просек који се користи за процену преосталог времена. Према овој методи, ако је дип трајао само 10 секунди, а затим се вратио на 1 МБ / с, мало је вероватно да ће корисник приметити разлику (осим за веома мали застој у предвиђеном временском одбројавању).

Како доћи до месинга - то је једноставно методологија за преношење информација крајњем кориснику за стварни узрок ...

Не можете прецизно одредити нешто што је недетерминистичко

У крајњој линији, нетачност у напретку се своди на чињеницу да покушава да одреди време за нешто што је недетерминистичко. Пошто рачунари обрађују задатке и по захтеву иу позадини, готово је немогуће знати који ће системски ресурси бити доступни у било ком тренутку у будућности - а доступност системских ресурса је потребна да би било који задатак завршио..

Уз помоћ другог примера, претпоставимо да покрећете надоградњу програма на серверу који изводи прилично интензивну ажурирање базе података. Током овог процеса ажурирања, корисник затим шаље захтевни захтев другој бази података која ради на овом систему. Сада серверски ресурси, посебно за базу података, морају да обрађују захтеве и за вашу надоградњу, као и за кориснички покренуте упите - сценарио који ће сигурно бити узајамно штетан за време извршења. Алтернативно, корисник може да покрене захтев за пренос великих датотека који би оптеретио пропусност складиштења која би такође умањена перформансама. Или планирани задатак може покренути процес који покреће процес меморије. Добио си идеју.

Као, можда, реалнија инстанца за свакодневног корисника - размислите о покретању Виндовс Упдате или скенирања вируса. Обе ове операције изводе операције интензивних ресурса у позадини. Као резултат тога, напредак који сваки напредак зависи од онога што корисник тренутно ради. Ако читате е-пошту док се покреће, највероватније ће потражња за системским ресурсима бити ниска и трака напретка ће се досљедно кретати. С друге стране, ако радите уређивање графике онда ће ваша потражња за системским ресурсима бити много већа што ће проузроковати шизофренију покрета напредне траке.

Све у свему, једноставно је да нема кристалне кугле. Чак ни сам систем не зна под којим ће оптерећењем бити у било којем тренутку у будућности.

На крају крајева, то стварно није битно

Намера траке напретка је да, добро, указује на то да се заиста остварује напредак и да дотични процес није обешен. Лијепо је када је индикатор напретка точан, али обично је то само незнатна сметња када није. У већини случајева, програмери не намјеравају посветити много времена и труда у алгоритме напредне траке јер, искрено, има много важнијих задатака за трошење времена на.

Наравно, имате свако право да будете узнемирени када трака напретка скочи на 99% одмах, а онда чекате 5 минута за преосталих један посто. Али ако одговарајући програм функционише добро, само се подсетите да је програмер имао своје приоритете.