Mengapa Bar Kemajuan Begitu Tidak Akurat?

Pada awalnya, tampaknya menghasilkan estimasi waktu yang akurat seharusnya cukup mudah. Lagi pula, algoritma yang menghasilkan bilah kemajuan mengetahui semua tugas yang perlu dilakukan sebelumnya ... benar?

Untuk sebagian besar, memang benar bahwa algoritma sumber tidak tahu apa yang perlu dilakukan sebelumnya. Namun, menekan waktu yang diperlukan untuk melakukan setiap langkah adalah tugas yang sangat sulit, jika bukan hampir mustahil.

Semua Tugas Tidak Diciptakan Sama

Cara paling sederhana untuk mengimplementasikan bilah kemajuan adalah dengan menggunakan representasi grafis dari penghitung tugas. Di mana persen selesai hanya dihitung sebagai Tugas yang Selesai / Total Jumlah Tugas. Walaupun ini masuk akal secara logis pada pemikiran pertama, penting untuk diingat bahwa (jelas) beberapa tugas membutuhkan waktu lebih lama untuk diselesaikan.

Pertimbangkan tugas-tugas berikut yang dilakukan oleh penginstal:

1. Buat struktur folder.
2. Dekompresi dan salin file senilai 1 GB.
3. Buat entri registri.
4. Buat entri menu mulai.

Dalam contoh ini, langkah 1, 3, dan 4 akan selesai dengan sangat cepat sementara langkah 2 akan memakan waktu. Jadi bilah kemajuan yang bekerja pada hitungan sederhana akan melonjak menjadi 25% dengan sangat cepat, berhenti sebentar saat langkah 2 bekerja, dan kemudian melompat ke 100% hampir dengan segera.

Jenis implementasi ini sebenarnya sangat umum di antara progress bar karena, seperti yang disebutkan di atas, mudah untuk diimplementasikan. Namun, seperti yang Anda lihat, ini tergantung pada tugas yang tidak proporsional sebenarnya persentase kemajuan berkaitan dengan sisa waktu.

Untuk mengatasi ini, beberapa bilah kemajuan mungkin menggunakan implementasi di mana langkah-langkah tertimbang. Pertimbangkan langkah-langkah di atas di mana bobot relatif ditetapkan untuk setiap langkah:

1. Buat struktur folder. [Berat = 1]
2. Dekompresi dan salin file senilai 1 GB. [Berat = 7]
3. Buat entri registri. [Berat = 1]
4. Buat entri menu mulai. [Berat = 1]

Dengan menggunakan metode ini, bilah kemajuan akan bergerak dalam kenaikan 10% (karena berat totalnya 10) dengan langkah 1, 3, dan 4 memindahkan bilah 10% pada penyelesaian dan langkah 2 memindahkannya 70%. Meskipun tentu saja tidak sempurna, metode seperti ini adalah cara sederhana untuk menambahkan sedikit lebih akurat ke persentase bilah kemajuan.

Hasil Masa Lalu Tidak Menjamin Kinerja Masa Depan

Pertimbangkan contoh sederhana saya yang meminta Anda menghitung hingga 50 saat saya menggunakan stopwatch untuk menghitung waktu Anda. Katakanlah Anda menghitung sampai 25 dalam 10 detik. Akan masuk akal untuk mengasumsikan Anda akan menghitung angka yang tersisa dalam 10 detik tambahan, sehingga bilah kemajuan pelacakan ini akan menunjukkan 50% selesai dengan 10 detik tersisa.

Namun begitu hitungan Anda mencapai 25, saya mulai melempar bola tenis kepada Anda. Kemungkinan, ini akan mematahkan ritme Anda karena konsentrasi Anda telah berubah dari penghitungan angka yang ketat menjadi bola yang dihindari Anda. Dengan asumsi Anda dapat melanjutkan penghitungan, langkah Anda pasti sedikit melambat. Jadi sekarang progress bar masih bergerak, tetapi pada kecepatan yang jauh lebih lambat dengan perkiraan waktu yang tersisa baik macet atau benar-benar naik lebih tinggi.

Untuk contoh yang lebih praktis tentang ini, pertimbangkan pengunduhan file. Anda sedang mengunduh file 100 MB dengan kecepatan 1 MB / s. Ini sangat mudah untuk menentukan perkiraan waktu penyelesaian. Tapi 75% dari perjalanan ke sana, beberapa kemacetan jaringan hit dan laju unduhan Anda turun menjadi 500 KB / s.

Bergantung pada bagaimana browser menghitung waktu yang tersisa, ETA Anda dapat langsung berubah dari 25 detik menjadi 50 detik (hanya menggunakan kondisi sekarang: Ukuran Sisa / Kecepatan Unduhan) atau, kemungkinan besar, browser menggunakan algoritma rata-rata bergulir yang akan menyesuaikan fluktuasi kecepatan transfer tanpa menampilkan lompatan dramatis ke pengguna.

Contoh algoritme bergulir sehubungan dengan mengunduh file mungkin berfungsi seperti ini:

• Kecepatan transfer untuk 60 detik sebelumnya diingat dengan nilai terbaru menggantikan yang terlama (mis. Nilai 61 menggantikan yang pertama).
• Tingkat transfer efektif untuk tujuan perhitungan adalah rata-rata pengukuran ini.
• Sisa waktu dihitung sebagai: Ukuran Sisa / Kecepatan Pengunduhan yang Efektif

Jadi menggunakan skenario kami di atas (demi kesederhanaan, kami akan menggunakan 1 MB = 1.000 KB):

• Pada 75 detik setelah pengunduhan, 60 nilai yang kami ingat masing-masing akan menjadi 1.000 KB. Kecepatan transfer efektif adalah 1.000 KB (60.000 KB / 60) yang menghasilkan sisa waktu 25 detik (25.000 KB / 1.000 KB).
• Pada 76 detik (di mana kecepatan transfer turun menjadi 500 KB), kecepatan unduh efektif menjadi ~ 992 KB (59.500 KB / 60) yang menghasilkan sisa waktu ~ 24,7 detik (24.500 KB / 992 KB).
• Pada 77 detik: Kecepatan efektif = ~ 983 KB (59.000 KB / 60) menghasilkan sisa waktu ~ 24,4 detik (24.000 KB / 983 KB).
• Pada 78 detik: Kecepatan efektif = 975 KB (58.500 KB / 60) menghasilkan sisa waktu ~ 24,1 detik (23.500 KB / 975 KB).

Anda dapat melihat pola yang muncul di sini karena penurunan kecepatan unduhan perlahan dimasukkan ke dalam rata-rata yang digunakan untuk memperkirakan waktu yang tersisa. Di bawah metode ini, jika dip hanya bertahan selama 10 detik dan kemudian kembali ke 1 MB / s pengguna tidak akan melihat perbedaannya (simpan untuk warung yang sangat kecil dalam hitungan mundur perkiraan waktu).

Mendapatkan ke pijakan kuningan - ini hanyalah metodologi untuk menyampaikan informasi kepada pengguna akhir untuk penyebab mendasar yang sebenarnya ...

Anda Tidak Dapat Secara Akurat Menentukan Sesuatu yang Tidak Menentu

Pada akhirnya, progress bar ketidaktepatan bermuara pada fakta bahwa ia sedang mencoba menentukan waktu untuk sesuatu yang tidak deterministik. Karena komputer memproses tugas baik berdasarkan permintaan maupun di latar belakang, hampir tidak mungkin untuk mengetahui sumber daya sistem apa yang akan tersedia di titik mana pun di masa depan - dan ketersediaan sumber daya sistem yang diperlukan untuk menyelesaikan tugas apa pun.

Menggunakan contoh lain, misalkan Anda menjalankan pemutakhiran program pada server yang melakukan pembaruan basis data yang cukup intensif. Selama proses pembaruan ini, seorang pengguna kemudian mengirimkan permintaan yang menuntut ke database lain yang berjalan pada sistem ini. Sekarang sumber daya server, khususnya untuk basis data, harus memproses permintaan untuk peningkatan Anda maupun permintaan yang dimulai pengguna - sebuah skenario yang tentunya akan saling merugikan waktu eksekusi. Sebagai alternatif, pengguna dapat memulai permintaan transfer file besar yang akan membebani throughput penyimpanan yang akan mengurangi kinerja juga. Atau tugas yang dijadwalkan dapat dimulai yang melakukan proses intensif memori. Anda mendapatkan idenya.

Sebagai, mungkin, contoh yang lebih realistis untuk pengguna sehari-hari - pertimbangkan untuk menjalankan Pembaruan Windows atau pemindaian virus. Kedua operasi ini melakukan operasi intensif sumber daya di latar belakang. Akibatnya, kemajuan masing-masing tergantung pada apa yang dilakukan pengguna pada saat itu. Jika Anda membaca email saat ini berjalan, kemungkinan besar permintaan akan sumber daya sistem akan rendah dan bilah kemajuan akan bergerak secara konsisten. Di sisi lain, jika Anda melakukan editing grafik maka permintaan Anda pada sumber daya sistem akan jauh lebih besar yang akan menyebabkan pergerakan progress bar menjadi skizofrenia..

Secara keseluruhan, hanya saja tidak ada bola kristal. Bahkan sistem itu sendiri tidak tahu beban apa yang ada di bawah pada titik mana pun di masa depan.

Pada akhirnya, Ini Benar-Benar Tidak Masalah

Maksud dari progress bar adalah untuk, yah, mengindikasikan bahwa kemajuan memang sedang dibuat dan proses masing-masing tidak digantung. Itu bagus ketika indikator kemajuan akurat, tetapi biasanya itu hanya gangguan kecil ketika tidak. Untuk sebagian besar, pengembang tidak akan mencurahkan banyak waktu dan usaha ke dalam algoritma progress bar karena, terus terang, ada tugas yang jauh lebih penting untuk menghabiskan waktu di.

Tentu saja, Anda berhak kesal ketika bilah kemajuan melonjak menjadi 99% secara instan dan kemudian membuat Anda menunggu 5 menit untuk satu persen sisanya. Tetapi jika masing-masing program bekerja dengan baik secara keseluruhan, hanya mengingatkan diri sendiri bahwa pengembang memiliki prioritas yang benar.