Kāpēc progresa stieņi ir tik neprecīzi?

Pirmajā domā, šķiet, ka precīzai laika aprēķināšanai vajadzētu būt samērā vienkāršai. Galu galā, progresa joslu veidojošais algoritms zina visus uzdevumus, kas tai jādara pirms laika… labi?

Lielākoties tas ir taisnība, ka avota algoritms zina, kas tam jādara pirms laika. Tomēr laiks, kas nepieciešams, lai veiktu katru soli, ir ļoti sarežģīts, ja ne praktiski neiespējams uzdevums.

Visi uzdevumi nav izveidoti vienādi

Vienkāršākais veids, kā īstenot progresa joslu, ir grafiskā uzdevuma skaitītāja attēlošana. Ja procenti ir pilnībā aprēķināti kā Pabeigtie uzdevumi / kopējais uzdevumu skaits. Lai gan tas ir loģiski saprotams pēc pirmās domāšanas, ir svarīgi atcerēties, ka (acīmredzot) dažiem uzdevumiem ir nepieciešams ilgāks laiks.

Apsveriet šādus uzdevumus, ko veic instalētājs:

1. Izveidot mapju struktūru.
2. Atspiest un kopēt 1 GB lielu failu skaitu.
3. Izveidojiet reģistra ierakstus.
4. Izveidojiet sākuma izvēlnes ierakstus.

Šajā piemērā 1., 3. un 4. solis pabeigtu ļoti ātri, bet 2. solis prasītu kādu laiku. Līdz ar to progresa josla, kas strādā pie vienkārša skaita, ļoti ātri pārietu uz 25%, mazliet apstāsies, kamēr 2. solis darbojas, un pēc tam uzreiz pāriet uz 100%.

Šis īstenošanas veids faktiski ir diezgan izplatīts starp progresa joslām, jo, kā minēts iepriekš, tas ir viegli īstenojams. Tomēr, kā jūs redzat, tas ir pakļauts nesamērīgiem uzdevumiem, kas sagroza faktiski progresa procentuālā daļa, kas saistīta ar atlikušo laiku.

Lai to paveiktu, daži progresa joslas var izmantot implementācijas, kurās soļi tiek svērti. Apsveriet iepriekš minētās darbības, kurās katram solim tiek piešķirts relatīvais svars:

1. Izveidot mapju struktūru. [Svars = 1]
2. Atspiest un kopēt 1 GB lielu failu skaitu. [Svars = 7]
3. Izveidojiet reģistra ierakstus. [Svars = 1]
4. Izveidojiet sākuma izvēlnes ierakstus. [Svars = 1]

Izmantojot šo metodi, progresa josla pārvietotos pa 10% (kā kopējais svars ir 10) ar 1., 3. un 4. darbību, pārvietojot stieni 10% pēc pabeigšanas un 2. soli pārvietojot to 70%. Lai gan, protams, tas nav perfekts, tādas metodes ir vienkāršs veids, kā pievienot bitu precizitāti progresa joslas procentam.

Iepriekšējie rezultāti negarantē nākotnes sniegumu

Apsveriet vienkāršu man piemēru, lūdzot, lai jūs skaitītu līdz 50, kamēr es laiku lietoju hronometru. Pieņemsim, ka 10 sekunžu laikā jūs skaitīsiet līdz 25. Būtu pamatoti pieņemt, ka atlikušos skaitļus aprēķināsit vēl 10 sekunžu laikā, tāpēc progresa josla uzskaite, kas parādītu 50%, ir 10 sekundes..

Tiklīdz jūsu skaitlis sasniedz 25, es sāku tev uzlikt tenisa bumbas. Iespējams, tas izjauks jūsu ritmu, jo jūsu koncentrācija ir pārgājusi no stingri skaitāmiem skaitļiem, lai izvairītos no bumbām, kas izmet savu ceļu. Pieņemot, ka jūs varat turpināt skaitīšanu, jūsu temps noteikti ir palēninājies. Tāpēc progresa josla joprojām virzās, bet daudz lēnākā tempā ar paredzamo laiku, kas paliek vai nu apstājoties, vai faktiski kāpjot augstāk.

Lai iegūtu praktiskāku piemēru tam, apsveriet faila lejupielādi. Jūs pašlaik lejupielādējat 100 MB failu ar ātrumu 1 MB / s. Tas ir ļoti viegli noteikt paredzamo pabeigšanas laiku. Bet 75% no tā, daži tīkla sastrēgumu hits un jūsu lejupielādes ātrums samazinās līdz 500 KB / s.

Atkarībā no tā, kā pārlūkprogramma aprēķina atlikušo laiku, jūsu ETA varētu uzreiz pāriet no 25 sekundēm līdz 50 sekundēm (tikai izmantojot pašreizējo stāvokli: Atlikušais izmērs / lejupielādes ātrums) vai, visticamāk, pārlūkprogramma izmanto ritošā vidējā algoritmu, kas pielāgotu pārsūtīšanas ātruma svārstībām, neparādot dramatiskus lēcienus lietotājam.

Ritošā algoritma piemērs, kas attiecas uz faila lejupielādi, varētu darboties šādi:

• Pārsūtīšanas ātrums iepriekšējās 60 sekundēs tiek atcerēts ar jaunāko vērtību, kas aizstāj vecāko (piemēram, 61. vērtība aizstāj pirmo).
• Efektīvais pārsūtīšanas ātrums aprēķina nolūkā ir šo mērījumu vidējais lielums.
• Atlikušais laiks tiek aprēķināts kā: Atlikušais izmērs / efektīvais lejupielādes ātrums

Tātad, izmantojot iepriekš minēto scenāriju (vienkāršības labad mēs izmantosim 1 MB = 1000 KB):

• Lejupielādējot 75 sekundes, mūsu 60 atcerētās vērtības būtu 1000 KB. Efektīvais pārsūtīšanas ātrums ir 1000 KB (60 000 KB / 60), kas rada atlikušo laiku 25 sekundes (25 000 KB / 1000 KB).
• 76 sekundēs (ja pārsūtīšanas ātrums samazinās līdz 500 KB), faktiskais lejupielādes ātrums kļūst par ~ 992 KB (59,500 KB / 60), kas dod laiku, kas paliek ~ 24,7 sekundes (24 500 KB / 992 KB).
• 77 sekundēs: efektīvais ātrums = ~ 983 KB (59 000 KB / 60), kas nodrošina atlikušo laiku ~ 24,4 sekundes (24 000 KB / 983 KB).
• 78 sekundēs: efektīvais ātrums = 975 KB (58,500 KB / 60), kas nodrošina atlikušo laiku ~ 24,1 sekundes (23 500 KB / 975 KB).

Jūs varat redzēt šeit parādīto modeli, jo lejupielādes ātruma kritums ir lēnām iekļauts vidējā vērtībā, kas tiek izmantota, lai novērtētu atlikušo laiku. Saskaņā ar šo metodi, ja iemērkšana ilga tikai 10 sekundes un pēc tam atgriezās 1 MB / s, lietotājam, visticamāk, netiks novērota atšķirība (izņemot ļoti nelielu apturēšanu paredzamajā laika atpakaļskaitīšanā).

Nokļūšana pie misiņa spilventiņiem - tā ir vienkārši metodika, lai gala lietotājam nodotu informāciju par faktisko pamatcēloni ...

Jūs nevarat precīzi noteikt kaut ko, kas nav necieterminisks

Galu galā progresa joslas neprecizitāte sakrīt ar to, ka tā cenšas noteikt laiku, kas ir kaut kas nenoteikts. Tā kā datori apstrādā uzdevumus gan pēc pieprasījuma, gan fonā, ir gandrīz neiespējami zināt, kādi sistēmas resursi būs pieejami jebkurā brīdī nākotnē - un tas ir sistēmas resursu pieejamība, kas nepieciešama jebkuram uzdevumam..

Izmantojot citu piemēru, pieņemsim, ka jūs izmantojat programmas jaunināšanu serverī, kas veic diezgan intensīvu datu bāzes atjauninājumu. Šī atjaunināšanas procesa laikā lietotājs pēc tam nosūta prasīgu pieprasījumu citai datu bāzei, kas darbojas šajā sistēmā. Tagad servera resursiem, īpaši datu bāzei, ir jāpārstrādā pieprasījumi gan par jaunināšanu, gan lietotāja ierosinātajiem vaicājumiem - scenārijs, kas noteikti būs savstarpēji kaitīgs izpildes laikam. Alternatīvi, lietotājs var uzsākt lielu failu pārsūtīšanas pieprasījumu, kas apliktu ar nodokli uzglabāšanas caurlaidspēju, kas arī mazinātu veiktspēju. Vai ieplānotais uzdevums varētu sākt darbu, kas veic intensīvu atmiņu. Jūs saņemsiet ideju.

Kā, iespējams, reālistiskāks gadījums ikdienas lietotājam - apsveriet iespēju izmantot Windows atjaunināšanu vai vīrusu skenēšanu. Abas šīs darbības veic resursu ietilpīgas darbības fonā. Rezultātā katra izstrādājuma attīstība ir atkarīga no tā, ko lietotājs dara tajā laikā. Ja lasāt e-pastu, kamēr tas notiek, visticamāk, pieprasījums pēc sistēmas resursiem būs zems un progresa josla vienmērīgi mainīsies. No otras puses, ja jūs veicat grafikas rediģēšanu, tad jūsu pieprasījums pēc sistēmas resursiem būs daudz lielāks, kas radīs progresa joslas kustību šizofrēnai.

Kopumā vienkārši ir tas, ka kristāla bumba nav. Pat sistēma pati nezina, kāda slodze būs zemāka jebkurā brīdī nākotnē.

Galu galā, tas tiešām nav svarīgi

Progresa joslas nolūks ir, labi, norādīt, ka patiešām tiek panākts progress, un attiecīgais process nav piekārts. Tas ir jauki, ja progresa indikators ir precīzs, bet parasti tas ir tikai neliels kairinājums, ja tas nav. Izstrādātāji lielākoties neplānos veltīt laiku un pūles progresa joslas algoritmiem, jo, atklāti sakot, ir daudz svarīgāki uzdevumi, lai pavadītu laiku.

Protams, jums ir visas tiesības tikt sajukušam, kad progresa josla uzreiz paceļas uz 99% un pēc tam liek jums pagaidīt 5 minūtes atlikušajam procentam. Bet, ja attiecīgā programma darbojas labi, vienkārši atgādiniet, ka attīstītājam bija savas prioritātes.