İlerleme Çubukları Neden Yanlış?

İlk düşüncede, doğru bir zaman tahmini oluşturmanın oldukça kolay olması gerektiği görülmektedir. Sonuçta, ilerleme çubuğunu üreten algoritma önceden yapması gereken tüm görevleri bilir… doğru?

Çoğunlukla, kaynak algoritmasının vaktinden önce ne yapması gerektiğini bildiği doğrudur. Ancak, her adımı gerçekleştirmek için harcayacağınız zamanı belirlemek, neredeyse imkansız olmasa da, çok zordur..

Tüm Görevler Eşit Olmaz

İlerleme çubuğu uygulamanın en basit yolu, görev sayacının grafik gösterimini kullanmaktır. Yüzde tamamlamanın basitçe olarak hesaplandığı yer Tamamlanan Görevler / Toplam Görev Sayısı. Bu ilk düşünceye mantıklı gelse de, (belli ki) bazı görevlerin tamamlanmasının daha uzun sürdüğünü hatırlamak önemlidir..

Bir yükleyici tarafından gerçekleştirilen aşağıdaki görevleri göz önünde bulundurun:

1. Klasör yapısı oluştur.
2. 1 GB değerinde dosyanın sıkıştırmasını açın ve kopyalayın.
3. Kayıt defteri girişleri oluşturun.
4. Başlat menüsü girişleri oluşturun.

Bu örnekte, adım 1, 3 ve 4 çok hızlı bir şekilde tamamlanırken, adım 2 biraz zaman alacaktı. Böylece, basit bir sayımda çalışan bir ilerleme çubuğu çok hızlı bir şekilde% 25'e yükselir, 2. adım çalışırken biraz durur ve hemen hemen% 100'e atlar..

Bu tür bir uygulama aslında ilerleme çubukları arasında oldukça yaygındır, çünkü yukarıda belirtildiği gibi uygulanması kolaydır. Ancak, görebileceğiniz gibi, bu sorunu gideren orantısız görevlere tabidir. gerçek Kalan süre ile ilgili olarak ilerleme yüzdesi.

Bu soruna geçici bir çözüm bulmak için, bazı ilerleme çubukları, adımların ağırlıklı olduğu uygulamaları kullanabilir. Her bir adıma göreceli ağırlığın atandığı yukarıdaki adımları göz önünde bulundurun:

1. Klasör yapısı oluşturun. [Ağırlık = 1]
2. 1 GB değerinde dosyayı açın ve kopyalayın. [Ağırlık = 7]
3. Kayıt defteri girişleri oluşturun. [Ağırlık = 1]
4. Başlat menüsü girişleri oluşturun. [Ağırlık = 1]

Bu yöntemi kullanarak, ilerleme çubuğu% 10'luk bir artışla (toplam ağırlık 10 olduğu için) adım 1, 3 ve 4 ile hareket halinde çubuğu% 10 hareket ettirir ve adım 2 bunu% 70 hareket ettirir. Kesinlikle mükemmel olmasa da, bu gibi yöntemler ilerleme çubuğu yüzdesine biraz daha fazla doğruluk eklemek için basit bir yoldur.

Geçmiş Sonuçlar Gelecekteki Performansı Garantilemiyor

Size zaman ayırmak için bir kronometre kullanırken, sizden 50'ye kadar saymanızı istemek için basit bir örnek düşünün. Diyelim ki 10 saniyede 25'e kadar sayın. Kalan sayıları 10 saniyede ekleyeceğinizi varsaymanız makul olacaktır, bu nedenle bunu izleyen bir ilerleme çubuğu 10 saniye kalan% 50 oranında tamamlanmış olur.

Ancak sayınız 25'e ulaştığında, size tenis topu atmaya başlıyorum. Muhtemelen, konsantrasyonunuz kesinlikle sayılardan kaçan toplardan atılan toplara doğru ilerlerken, bu ritminizi bozacaktır. Saymaya devam edebileceğinizi varsayarsak, hızınız kesinlikle biraz yavaşladı. Şimdi, ilerleme çubuğu hala hareket ediyor, ancak durma anında veya gerçekte daha yükseğe çıkma süresi tahmin edilen süre ile çok daha yavaş.

Bunun daha pratik bir örneği için, bir dosya indirmeyi düşünün. Şu anda 1 MB / s hızında 100 MB'lık bir dosya indiriyorsunuz. Tahmini tamamlanma zamanını belirlemek çok kolaydır. Ancak, oradaki yolun% 75’i, bazı ağ tıkanıklıklarını vuruyor ve indirme oranınız 500 KB / s’ye düşüyor.

Tarayıcının kalan zamanı nasıl hesapladığına bağlı olarak, ETA'nız anında 25 saniyeden 50 saniyeye kadar gidebilir (yalnızca şu anki durumu kullanarak: Kalan Boyut / İndirme Hızı) veya, büyük olasılıkla, tarayıcı kullanıcıya çarpıcı atlamalar göstermeden aktarım hızındaki dalgalanmalara uyum sağlayacak bir yuvarlanma ortalama algoritması kullanır.

Bir dosyanın indirilmesine ilişkin bir yuvarlanma algoritması örneği şunun gibi olabilir:

• Önceki 60 saniyenin transfer hızı, en eski olanın yerine geçen en yeni değerle hatırlanır (örneğin, 61. değer ilk olanın yerine geçer).
• Hesaplama amacıyla kullanılan efektif transfer oranı, bu ölçümlerin ortalamasıdır..
• Kalan süre şu şekilde hesaplanır: Kalan Boyut / Etkili İndirme Hızı

Bu yüzden yukarıdaki senaryomuzu kullanarak (basitlik uğruna, 1 MB = 1,000 KB kullanacağız):

• İndirmeye 75 saniyede, 60 hatırladığımız değerin her biri 1.000 KB olacaktır. Etkili aktarım hızı 1.000 KB'dir (60.000 KB / 60), bu da 25 saniyelik (25.000 KB / 1.000 KB) kalan bir süre sağlar.
• 76 saniyede (aktarım hızının 500 KB'ye düştüğü), etkili indirme hızı ~ 992 KB (59.500 KB / 60) olur, bu da ~ 24.7 saniye (24.500 KB / 992 KB) kalan bir zaman kazandırır.
• 77 saniyede: Etkin hız = ~ 983 KB (59.000 KB / 60), ~ 24.4 saniye (24.000 KB / 983 KB) kalan zaman.
• 78 saniyede: Etkin hız = 975 KB (58.500 KB / 60), ~ 24.1 saniye (23.500 KB / 975 KB) kalan zaman.

Burada ortaya çıkan paterni görebilirsiniz, çünkü indirme hızındaki düşüş, kalan süreyi tahmin etmek için kullanılan ortalamaya yavaşça dahil edilir. Bu yönteme göre, eğer daldırma sadece 10 saniye sürdüyse ve 1 MB / s'ye geri dönerse, kullanıcının farkı fark etmesi muhtemel değildir (tahmini zaman geri sayımında çok küçük bir duraklama için tasarruf edin).

Pirinç parçalarına ulaşmak - bu sadece asıl sebep için son kullanıcıya bilgi aktarma metodolojisidir…

Belirsiz bir şeyi kesin olarak belirleyemezsiniz

Sonuçta, ilerleme çubuğu yanlışlığı, özgün olmayan bir şey için bir zaman belirlemeye çalıştığı gerçeğinden kaynaklanmaktadır. Bilgisayarlar hem talep üzerine hem de arka planda görevlerini işlediklerinden, gelecekte herhangi bir noktada hangi sistem kaynaklarının kullanılacağını bilmek neredeyse imkansızdır - ve herhangi bir görevin tamamlanması için gereken sistem kaynaklarının kullanılabilirliğidir..

Başka bir örnek kullanarak, oldukça yoğun bir veritabanı güncellemesi gerçekleştiren bir sunucuda bir program güncellemesi yaptığınızı varsayalım. Bu güncelleme işlemi sırasında, bir kullanıcı daha sonra bu sistemde çalışan başka bir veritabanına zorlu bir istek gönderir. Şimdi, özellikle veritabanı için olan sunucu kaynakları, hem yükseltme işleminiz hem de kullanıcı tarafından başlatılan sorgu için istekleri işleme koymak zorunda kalmaktadır - yürütme zamanına kesinlikle karşılıklı olarak zarar verecek bir senaryo. Alternatif olarak, bir kullanıcı, performanstan da zarar verecek olan depolama hacmini vergilendirecek büyük bir dosya aktarma isteği başlatabilir. Veya zamanlanmış bir görev, yoğun bellek kullanan bir işlemi gerçekleştirebilir. Kaptın bu işi.

Gündelik bir kullanıcı için belki de daha gerçekçi bir örnek olarak, Windows Update veya virüs taraması yapmayı düşünün. Bu işlemlerin her ikisi de arka planda kaynak yoğun işlemleri gerçekleştirir. Sonuç olarak, her birinin kaydettiği ilerleme, kullanıcının o sırada ne yaptığına bağlıdır. Bu sırada e-postanızı okuyorsanız, büyük olasılıkla sistem kaynaklarına olan talep düşük olacak ve ilerleme çubuğu tutarlı bir şekilde hareket edecektir. Öte yandan, grafik düzenleme yapıyorsanız, sistem kaynaklarına olan talebiniz, ilerleme çubuğu hareketinin şizofrenik olmasına neden olacak şekilde çok daha büyük olacaktır..

Genel olarak, basitçe kristal topun olmamasıdır. Sistemin kendisi bile gelecekte hangi noktada yükleneceğini bilmiyor.

Sonuçta, Gerçekten Önemli Değil

İlerleme çubuğunun amacı, ilerlemenin gerçekten yapılmakta olduğunu ve ilgili sürecin askıya alınmadığını göstermektir. İlerleme göstergesi doğru olduğunda güzeldir, ancak genellikle doğru olmadığında yalnızca küçük bir sıkıntı olur. Çoğunlukla, geliştiriciler ilerleme çubuğu algoritmalarına çok fazla zaman ve çaba harcayacaklar, çünkü açıkçası zaman harcayacak çok daha önemli görevler var..

Elbette, bir ilerleme çubuğu anında% 99'lara ulaştığında ve sonra kalan yüzde bir için 5 dakika beklettiğinde sinirlenmeye hakkın vardır. Ancak, ilgili program genel olarak iyi çalışıyorsa, geliştiricinin önceliklerini belirlediğini kendinize hatırlatın.