प्रगति बार्स इतनी गलत क्यों हैं?

2024 लेखक: Geoffrey Carr | [email protected]. अंतिम बार संशोधित: 2023-12-17 11:00

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

आखिरकार, यह वास्तव में मामला नहीं है

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

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