क्यों प्रगतिशील सलाखों तो गलत हैं?

पहले सोचा, ऐसा लगता है कि समय का सटीक अनुमान उत्पन्न करना काफी आसान होना चाहिए। आखिरकार, प्रगति पट्टी का निर्माण करने वाला एल्गोरिथ्म उन सभी कार्यों को जानता है जो इसे समय से पहले करने की आवश्यकता है ... सही है?

अधिकांश भाग के लिए, यह सच है कि स्रोत एल्गोरिथ्म को पता है कि उसे समय से पहले क्या करना है। हालांकि, प्रत्येक चरण को पूरा करने में लगने वाले समय को कम करना, बहुत मुश्किल है, यदि वास्तव में असंभव नहीं है, तो कार्य.

सभी कार्य समान नहीं हैं

प्रगति बार को लागू करने का सबसे सरल तरीका कार्य काउंटर के चित्रमय प्रतिनिधित्व का उपयोग करना है। जहां प्रतिशत पूर्ण रूप से गणना की जाती है पूर्ण कार्य / कार्य की कुल संख्या. हालांकि यह पहले विचार पर तार्किक समझ में आता है, यह याद रखना महत्वपूर्ण है कि (स्पष्ट रूप से) कुछ कार्यों को पूरा होने में अधिक समय लगता है.

इंस्टॉलर द्वारा किए गए निम्नलिखित कार्यों पर विचार करें:

1. फ़ोल्डर संरचना बनाएँ.
2. डीकंप्रेस और कॉपी 1 जीबी मूल्य की फाइलें.
3. रजिस्ट्री प्रविष्टियां बनाएं.
4. प्रारंभ मेनू प्रविष्टियाँ बनाएँ.

इस उदाहरण में, चरण 1, 3 और 4 बहुत जल्दी पूरा हो जाएगा जबकि चरण 2 में कुछ समय लगेगा। तो एक साधारण गिनती पर काम कर रहा एक प्रगति बार बहुत जल्दी 25% तक बढ़ जाएगा, स्टेप 2 काम करते समय थोड़ा रुकना होगा, और फिर लगभग तुरंत 100% कूदना होगा.

इस प्रकार का कार्यान्वयन वास्तव में प्रगति सलाखों के बीच काफी सामान्य है, क्योंकि जैसा कि ऊपर कहा गया है, इसे लागू करना आसान है। हालाँकि, जैसा कि आप देख सकते हैं, यह तिरछा कार्यों को तिरस्कार करने के अधीन है वास्तविक प्रगति प्रतिशत के रूप में यह शेष समय से संबंधित है.

इसके चारों ओर काम करने के लिए, कुछ प्रगति पट्टियाँ कार्यान्वयन का उपयोग कर सकती हैं जहाँ कदम भारित होते हैं। उपरोक्त चरणों पर विचार करें जहां प्रत्येक चरण के लिए एक सापेक्ष भार सौंपा गया है:

1. फ़ोल्डर संरचना बनाएँ। [वजन = १]
2. डीकंप्रेस और कॉपी 1 जीबी मूल्य की फाइलें। [वजन = =]
3. रजिस्ट्री प्रविष्टियां बनाएं। [वजन = १]
4. प्रारंभ मेनू प्रविष्टियाँ बनाएँ। [वजन = १]

इस विधि का उपयोग करते हुए, प्रगति बार 10% की वृद्धि में कदम होगा (कुल वजन 10 है) चरण 1, 3, और 4 के साथ और 10 बार पूरा होने पर चरण 2 और चरण 2 इसे 70% तक ले जाएगा। हालांकि निश्चित रूप से सही नहीं है, इस तरह के तरीके प्रगति बार प्रतिशत में थोड़ी अधिक सटीकता जोड़ने का एक सरल तरीका है.

पिछले परिणाम भविष्य के प्रदर्शन की गारंटी नहीं देते हैं

मेरे एक साधारण उदाहरण पर विचार करें जब मैं आपको स्टॉपवॉच का उपयोग करते हुए 50 से गिनती करने के लिए कहता हूं। मान लीजिए कि आप 10 सेकंड में 25 तक गिनती करते हैं। यह मान लेना उचित होगा कि आप शेष संख्याओं को अतिरिक्त 10 सेकंड में गिनेंगे, इसलिए इस पर नज़र रखने वाला एक प्रगति पट्टी 10% शेष 50% पूरा दिखाएगा.

एक बार जब आपकी गिनती 25 तक पहुँच जाती है, हालाँकि, मैं आप पर टेनिस बॉल फेंकना शुरू करता हूँ। इस तरह, यह आपकी लय को तोड़ देगा क्योंकि आपकी एकाग्रता सख्ती से गिनती की संख्या से बढ़ कर गेंदों को आपके रास्ते में फेंक रही है। यह मानते हुए कि आप गिनती जारी रखने में सक्षम हैं, आपकी गति निश्चित रूप से थोड़ी धीमी हो गई है। तो अब प्रगति पट्टी अभी भी आगे बढ़ रही है, लेकिन एक धीमी गति से धीमी गति से या तो ठहराव के समय या वास्तव में ऊंची चढ़ाई पर.

इसके अधिक व्यावहारिक उदाहरण के लिए, एक फ़ाइल डाउनलोड पर विचार करें। आप वर्तमान में 1 एमबी / एस की दर से 100 एमबी फ़ाइल डाउनलोड कर रहे हैं। यह पूरा होने का अनुमानित समय निर्धारित करना बहुत आसान है। लेकिन 75% वहाँ, कुछ नेटवर्क भीड़ हिट और आपकी डाउनलोड दर 500 KB / s तक गिर जाती है.

ब्राउज़र शेष समय की गणना कैसे करता है, इसके आधार पर, आपका ईटीए तुरंत 25 सेकंड से 50 सेकंड तक जा सकता है (केवल वर्तमान स्थिति का उपयोग करके: आकार शेष / डाउनलोड गति) या, सबसे अधिक संभावना है, ब्राउज़र एक रोलिंग औसत एल्गोरिथ्म का उपयोग करता है जो उपयोगकर्ता को नाटकीय कूदता प्रदर्शित किए बिना स्थानांतरण गति में उतार-चढ़ाव के लिए समायोजित करेगा।.

फ़ाइल डाउनलोड करने के संबंध में रोलिंग एल्गोरिथम का एक उदाहरण कुछ इस तरह से काम कर सकता है:

• पिछले 60 सेकंड के लिए स्थानांतरण गति को सबसे पुराने के स्थान पर सबसे नए मान के साथ याद किया जाता है (उदाहरण के लिए 61 वाँ मान पहले).
• गणना के उद्देश्य के लिए प्रभावी हस्तांतरण दर इन मापों का औसत है.
• शेष समय की गणना इस प्रकार की जाती है: आकार शेष / प्रभावी डाउनलोड गति

तो ऊपर हमारे परिदृश्य का उपयोग करते हुए (सादगी के लिए, हम 1 एमबी = 1,000 केबी का उपयोग करेंगे):

• डाउनलोड में 75 सेकंड पर, हमारे 60 याद किए गए मूल्य प्रत्येक 1,000 केबी होंगे। प्रभावी हस्तांतरण दर 1,000 केबी (60,000 केबी / 60) है जो 25 सेकंड (25,000 केबी / 1,000 केबी) के बचे समय की उपज देता है.
• 76 सेकंड पर (जहां स्थानांतरण गति 500 ​​KB तक गिरती है), प्रभावी डाउनलोड गति ~ 992 KB (59,500 KB / 60) हो जाती है, जो ~ 24.7 सेकंड (24,500 KB / 992 KB) शेष समय देता है.
• 77 सेकंड पर: प्रभावी गति = ~ 983 KB (59,000 KB / 60) शेष समय ~ 24.4 सेकंड (24,000 KB / 983 KB).
• 78 सेकंड पर: प्रभावी गति = 975 KB (58,500 KB / 60) शेष समय ~ 24.1 सेकंड (23,500 KB / 975 KB).

आप यहां उभरने वाले पैटर्न को देख सकते हैं क्योंकि डाउनलोड गति में डुबकी को धीरे-धीरे औसत में शामिल किया जाता है जिसका उपयोग शेष समय का अनुमान लगाने के लिए किया जाता है। इस पद्धति के तहत, यदि डुबकी केवल 10 सेकंड तक चली और फिर 1 एमबी / एस पर वापस आ गई तो उपयोगकर्ता को अंतर नोटिस करने की संभावना नहीं है (अनुमानित समय उलटी गिनती में बहुत मामूली स्टाल के लिए बचाएं).

ब्रास टैक के लिए हो रही है - यह वास्तविक अंतर्निहित कारण के लिए अंतिम उपयोगकर्ता को जानकारी रिले करने के लिए बस कार्यप्रणाली है ...

आप सटीक रूप से कुछ निर्धारित नहीं कर सकते हैं जो नोंडेटर्मिनिस्टिक है

अंत में, प्रगति बार की अशुद्धि इस तथ्य से उबलती है कि यह किसी ऐसी चीज के लिए समय निर्धारित करने की कोशिश कर रहा है जो नॉनडेटर्मिनिस्टिक है। क्योंकि कंप्यूटर मांग और पृष्ठभूमि दोनों पर कार्य करता है, यह जानना लगभग असंभव है कि भविष्य में किसी भी बिंदु पर सिस्टम संसाधन क्या उपलब्ध होंगे - और यह सिस्टम संसाधनों की उपलब्धता है जिसे पूरा करने के लिए किसी भी कार्य की आवश्यकता होती है।.

एक और उदाहरण का उपयोग करते हुए, मान लीजिए कि आप एक सर्वर पर एक प्रोग्राम अपग्रेड चला रहे हैं जो एक काफी गहन डेटाबेस अपडेट करता है। इस अद्यतन प्रक्रिया के दौरान, एक उपयोगकर्ता तब इस सिस्टम पर चल रहे किसी अन्य डेटाबेस के लिए एक मांग अनुरोध भेजता है। अब सर्वर संसाधन, विशेष रूप से डेटाबेस के लिए, आपके अपग्रेड के साथ-साथ उपयोगकर्ता द्वारा क्वेरी शुरू करने के लिए अनुरोधों को संसाधित करने की आवश्यकता है - एक ऐसा परिदृश्य जो निश्चित रूप से निष्पादन समय के लिए पारस्परिक रूप से हानिकारक होगा। वैकल्पिक रूप से, एक उपयोगकर्ता एक बड़ी फ़ाइल स्थानांतरण अनुरोध शुरू कर सकता है जो भंडारण थ्रूपुट पर कर लगाएगा जो प्रदर्शन से भी अलग होगा। या अनुसूचित कार्य बंद कर सकता है जो स्मृति गहन प्रक्रिया करता है। तुम्हें नया तरीका मिल गया है.

के रूप में, शायद, हर रोज़ उपयोगकर्ता के लिए अधिक यथार्थवादी उदाहरण - विंडोज अपडेट या वायरस स्कैन चलाने पर विचार करें। ये दोनों ऑपरेशन पृष्ठभूमि में संसाधन गहन संचालन करते हैं। परिणामस्वरूप, प्रत्येक प्रगति उस समय पर निर्भर करती है जो उपयोगकर्ता कर रहा है। यदि आप अपना ईमेल पढ़ रहे हैं तो यह चलता है, सबसे अधिक संभावना है कि सिस्टम संसाधनों की मांग कम होगी और प्रगति पट्टी लगातार बढ़ेगी। दूसरी ओर, यदि आप ग्राफिक्स एडिटिंग कर रहे हैं, तो सिस्टम रिसोर्स पर आपकी डिमांड बहुत ज्यादा हो जाएगी, जिससे प्रगति बार आंदोलन सिज़ोफ्रेनिक हो जाएगा.

कुल मिलाकर, यह बस इतना है कि कोई क्रिस्टल बॉल नहीं है। यहां तक ​​कि सिस्टम को भी नहीं पता है कि भविष्य में यह किसी भी बिंदु पर किस लोड के तहत होगा.

अंततः, इट रियली डू नॉट मैटर

प्रगति पट्टी का आशय, यह दर्शाता है कि प्रगति वास्तव में हो रही है और संबंधित प्रक्रिया लटका नहीं है। प्रगति सूचक सटीक होने पर यह अच्छा है, लेकिन आमतौर पर यह केवल एक छोटी सी झुंझलाहट है जब यह नहीं है। अधिकांश भाग के लिए, डेवलपर्स प्रगति बार एल्गोरिदम में समय और प्रयास का एक बड़ा हिस्सा समर्पित नहीं करने जा रहे हैं, क्योंकि, स्पष्ट रूप से, समय बिताने के लिए बहुत अधिक महत्वपूर्ण कार्य हैं.

बेशक, आपके पास हर अधिकार है कि आप परेशान हों जब एक प्रगति बार तुरंत 99% तक पूरा हो जाता है और फिर आपको शेष एक प्रतिशत के लिए 5 मिनट इंतजार करना पड़ता है। लेकिन अगर संबंधित कार्यक्रम कुल मिलाकर अच्छा काम करता है, तो बस अपने आप को याद दिलाएं कि डेवलपर की प्राथमिकताएं सीधे थीं.