>>>>,> |, ||, | <, <, <<

Question

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

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

क्या यह अस्तित्व में है? मेरी विशिष्ट आवश्यकता पायथन में है, लेकिन मुझे किसी भी भाषा में ऐसी कार्यक्षमता देखने में दिलचस्पी होगी।

Answer 1

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

प्रदर्शन समस्याओं को खोजने का एकमात्र तरीका एप्लिकेशन में किए गए प्रत्येक कॉल को रिकॉर्ड करना और कितना समय लगता है। यह एक प्रोफाइलर करता है। वास्तव में, एक प्रोफाइलर का उपयोग करना मुश्किल है, लेकिन शायद एक बेहतर विकल्प नहीं है। सिद्धांत रूप में आप प्रत्येक कॉल और प्रत्येक कॉल के समय को रिकॉर्ड कर सकते हैं, और उसके बाद पीछे और आगे एक रिवाइंड के साथ खेल सकते हैं, लेकिन यह एक आश्चर्यजनक मात्रा में स्मृति का उपयोग करेगा, और यह वास्तव में आपको प्रोफाइलर से कुछ और नहीं बताएगा (वास्तव में, यह आपको कम बताएगा, क्योंकि यह कुछ प्रकार की प्रदर्शन समस्याओं को याद करेगा)।

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

Answer 2

मुझे लगता है कि ऐप के निष्पादन में एक चरण है जो बहुत लंबा लगता है - यानी यह आपको प्रतीक्षा करता है। मुझे लगता है कि आप वास्तव में चाहते हैं कि यह देखने के लिए कि आप इसे तेज़ी से बदलने के लिए क्या बदल सकते हैं।

काम करने वाली तकनीक random-pausing है। आप डीबगर के तहत ऐप चलाते हैं, और इसके निष्पादन के हिस्से में जो आपको प्रतीक्षा करता है, इसे रोकता है, और कॉल स्टैक की जांच करता है। यह कुछ बार करो।

यहां कुछ तरीके हैं जिनसे आपका प्रोग्राम आवश्यकतानुसार अधिक समय व्यतीत कर सकता है।

• I/O जिसे आप नहीं जानते थे और वास्तव में इसकी आवश्यकता नहीं थी।
• वस्तुओं को आवंटित और जारी करना अक्सर।
• डेटा संरचनाओं पर रनवे अधिसूचनाएं।
• दूसरों भी कई उल्लेख करने के लिए ...

कोई फर्क नहीं पड़ता कि यह क्या है, जब यह हो रहा है, कॉल स्टैक की जांच यह दिखा देंगे। एक बार जब आप जानते हैं कि यह क्या है, तो आप इसे करने का बेहतर तरीका ढूंढ सकते हैं, या शायद यह बिल्कुल नहीं कर सकते हैं।

यदि कार्यक्रम में 1 सेकंड लगने पर 5 सेकंड लगते हैं, तो संभावना है कि आप प्रत्येक विराम पर समस्या देखेंगे 4/5 है। असल में, एक से अधिक स्टैक नमूने पर आप जो भी फ़ंक्शन कॉल देखते हैं, यदि आप इसे करने से बच सकते हैं, तो आपको एक महत्वपूर्ण गति मिल जाएगी। और, लगभग हर संभव बाधा को इस तरह से पाया जा सकता है।

फ़ंक्शन समय या कितनी बार उन्हें बुलाया जाता है, इसके बारे में मत सोचें। कोड की रेखाओं की तलाश करें जो अक्सर ढेर पर दिखाई देते हैं, जिनकी आपको आवश्यकता नहीं है।

उदाहरण जोड़ा गया: यदि आप ढेर के 5 नमूने लेते हैं, और उनमें से 2 पर दिखाई देने वाली कोड की एक पंक्ति है, तो यह समय के लगभग 2/5 = 40% के लिए ज़िम्मेदार है, दें या लें। आप सटीक प्रतिशत नहीं जानते हैं, और आपको जानने की आवश्यकता नहीं है। (तकनीकी रूप से, औसतन यह (2 + 1)/(5 + 2) = 3/7 = 43% खराब नहीं है, और आप जानते हैं कि यह कहां है।)

Answer 3

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

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