प्रगति पट्टी और एकाधिक धागे, डीयूओप्लिंग जीयूआई और तर्क - कौन सा डिजाइन पैटर्न सबसे अच्छा होगा?

Question

मैं एक डिजाइन पैटर्न की तलाश में हूं जो मेरे आवेदन डिजाइन में फिट होगा।

मेरा एप्लिकेशन बड़ी मात्रा में डेटा संसाधित करता है और कुछ ग्राफ उत्पन्न करता है। डेटा प्रोसेसिंग (फ़ाइलों से सीपीयू, सीपीयू गहन गणना) और ग्राफ ऑपरेशंस (ड्राइंग, अपडेटिंग) अलग थ्रेड में किए जाते हैं।

ग्राफ स्क्रॉल किया जा सकता है - इस मामले में नए डेटा भागों को संसाधित करने की आवश्यकता है। क्योंकि ग्राफ पर कई श्रृंखलाएं हो सकती हैं, कई धागे पैदा किए जा सकते हैं (प्रत्येक सेरी के दो धागे, डेटासेट अपडेट के लिए एक और ग्राफ़ अपडेट के लिए एक)।

मैं कई प्रगति सलाखों को नहीं बनाना चाहता हूं। इसके बजाय, मुझे एक प्रगति पट्टी चाहिए जो वैश्विक प्रगति के बारे में सूचित करे। फिलहाल मैं एमवीसी और पर्यवेक्षक/पर्यवेक्षक के बारे में सोच सकता हूं, लेकिन यह थोड़ा सा धुंधला है :) शायद कोई मुझे सही दिशा में इंगित कर सकता है, धन्यवाद।

Answer 1

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

जब मैं ऐसे डिज़ाइन प्रश्नों का उत्तर देने का प्रयास करता हूं तो मैं पहले अन्य एप्लिकेशन में समान या समान समस्याओं को देखने का प्रयास करता हूं, और उनका समाधान कैसे किया जाता है। तो मैं सुझाव दूंगा कि आप जटिल अनुप्रयोगों (जैसे डाउनलोड प्रबंधक उदाहरण) प्रदर्शित करने वाले अन्य अनुप्रयोगों पर विचार करके कुछ शोध करें और अपने आवेदन के मौजूदा समाधान को अनुकूलित करने का प्रयास करें।

क्षमा करें मैं अधिक विशिष्ट डिज़ाइन प्रदान नहीं कर सकता, यह केवल सामान्य सलाह है। :)

Answer 2

इस तरह की चीज़ के लिए पर्यवेक्षक/पर्यवेक्षक के साथ चिपकाएं। कुछ वस्तु सारांश बार अद्यतन करके विभिन्न श्रृंखला प्रसंस्करण धागे और रिपोर्ट की स्थिति को देखती है।

Answer 3

मैंने एक सप्ताह में सबसे जटिल एल्गोरिदम पर एक चिकनी, गैर-हिचक प्रगति पट्टी बनाने की कोशिश कर एक सप्ताह का सबसे अच्छा हिस्सा बिताया।

एल्गोरिदम में 6 अलग-अलग चरण थे। प्रत्येक चरण में समय की विशेषताओं थी जो ए पर गंभीर रूप से निर्भर थे) अंतर्निहित डेटा संसाधित किया जा रहा था, न केवल डेटा की "राशि" बल्कि डेटा के "प्रकार" और बी) चरण 2 में से 2 सीपीयू की बढ़ती संख्या के साथ बहुत अच्छी तरह से स्केल किए गए थे, 2 चरणों में 2 कदम भाग गए और 2 कदम प्रभावी ढंग से सिंगल-थ्रेडेड थे।

डेटा का मिश्रण प्रभावी रूप से कोर की संख्या से प्रत्येक चरण के निष्पादन समय पर बहुत बड़ा प्रभाव पड़ा।

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

f1 (..) + f2 (..) + f3 (..) + F4 (..) + F5 (..) + F6 (..) = मिलीसेकेंड

में कुल रनटाइम अब दिया यह जानकारी, आप प्रभावी ढंग से जान सकते हैं कि प्रत्येक चरण में कुल निष्पादन समय का प्रतिशत क्या है। अब यदि आप कहते हैं कि चरण 1 को निष्पादन समय का 40% लेना है, तो आपको मूल रूप से यह पता लगाना होगा कि उस एल्गोरिदम से 40%% ईवेंट कैसे निकालें।कहना के लिए लूप 100,000 आइटम संसाधित कर रहा है, तो आप शायद कर सकता है:

for (int i = 0; i < numItems; i++){ 
    if (i % (numItems/percentageOfTotalForThisStep) == 0) emitProgressEvent(); 
    .. do the actual processing .. 
} 

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

और हाँ, यह वास्तव में कोई फर्क नहीं था कि अनुमानी संदर्भ संख्या मेरी मशीन पर काम किया गया था - केवल वास्तविक समस्या है आप जब एक अलग मशीन पर चल संख्या को बदलना चाहते हैं। लेकिन आप अभी भी अनुपात जानते हैं (जो यहां केवल एकमात्र महत्वपूर्ण बात है), ताकि आप देख सकें कि आपका स्थानीय हार्डवेयर मेरे पास से अलग कैसे चलता है।

अब औसत एसओ रीडर आश्चर्य कर सकता है कि क्यों पृथ्वी पर कोई एक सप्ताह में एक चिकनी प्रगति पट्टी बनायेगा। इस सुविधा का मुख्य विक्रेता द्वारा अनुरोध किया गया था, और मेरा मानना ​​है कि उसने अनुबंध प्राप्त करने के लिए बिक्री मीटिंग में इसका इस्तेमाल किया था। मनी वार्ता;)

Answer 4

थ्रेड या एसिंक्रोनस प्रक्रियाओं/इस तरह के कार्यों के साथ स्थितियों में, मुझे मुख्य थ्रेड में एक सार प्रकार या ऑब्जेक्ट होना उपयोगी लगता है जो प्रत्येक प्रक्रिया को दर्शाता है (और आदर्श रूप से encapsulates)। इसलिए, प्रत्येक कार्यकर्ता धागे के लिए, संभावित रूप से उस ऑब्जेक्ट को प्रबंधित करने के लिए मुख्य थ्रेड में एक ऑब्जेक्ट होगा (चलो इसे Operation पर कॉल करें), और जाहिर है कि इन ऑपरेशंस को पकड़ने के लिए कुछ प्रकार की सूची-जैसी डेटा संरचना होगी।

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

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

जाहिर है/अन्य कारणों के लिए ढेर काम है कि वास्तव में इस को लागू करने में किया जा जरूरत है, लेकिन मैं यह आप इसे का सार देता है उम्मीद है।