पायथन प्रोफाइलिंग और डिबगिंग

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

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

बहुत सारी सामग्री है, लेख बहुत बड़ा था, इसलिए मैंने इसे कई हिस्सों में तोड़ने का फैसला किया:

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

परिचय

सबसे पहले, आपको परिभाषाओं से निपटने की आवश्यकता है। हम विकिपीडिया पर पढ़ते हैं :

प्रोफाइलिंग - उनके आगे अनुकूलन के लिए एक दृश्य के साथ कार्यक्रम की विशेषताओं को इकट्ठा करना।

इसलिए, प्रोफाइलिंग के लिए, हमें एक कार्यशील कार्यक्रम की आवश्यकता है, और यह बिल्कुल वैसे ही काम नहीं करेगा जैसा हम चाहेंगे: या तो बहुत धीरे-धीरे काम करना या बहुत अधिक संसाधनों का उपभोग करना।

कार्यक्रम की क्या विशेषताएं एकत्र की जा सकती हैं?

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

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

चलो "अनुकूलन" की अवधारणा को परिभाषित करते हैं। विकिपीडिया हमें बताता है कि:

अनुकूलन अपनी दक्षता में सुधार करने के लिए एक प्रणाली का एक संशोधन है।

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

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

दूसरी ओर, जैसा कि डोनाल्ड नुथ कहते थे: "समय से पहले का अनुकूलन सभी बीमारियों की जड़ है।"

इस उद्धरण के बिना अनुकूलन के बारे में क्या लेख है? कई लोगों का मानना ​​है कि इसका लेखक डोनाल्ड नुथ है, लेकिन खुद डोनाल्ड का दावा है कि एंथनी होयर ने पहली बार यह बात कही थी। दूसरी ओर, एंथोनी, "सार्वजनिक डोमेन" के उच्चारण पर विचार करने के लिए अनलॉक और प्रस्तावित करता है।

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

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

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

प्रोफाइल का अनुमोदन

कम से कम तीन रूपरेखा दृष्टिकोण हैं:

• टकटकी विधि
• मैनुअल प्रोफाइलिंग
• साधनों का उपयोग करना

टकटकी विधि (और इसके संबंधित " भाला विधि ") के साथ, सब कुछ स्पष्ट है। हम सिर्फ एक पाठ संपादक के सामने बैठते हैं, कोड खोलते हैं और सोचते हैं कि समस्या कहां हो सकती है, इसे ठीक करने की कोशिश करें, परिणाम देखें, वापस रोल करें। और केवल दुर्लभ मामलों में ( या डेवलपर की उच्चतम योग्यता के साथ ) विधि प्रभावी साबित होती है।

इस विधि के फायदे और नुकसान:
+ विशेष ज्ञान और कौशल की आवश्यकता नहीं है
- श्रम लागत और परिणामों का मूल्यांकन करना मुश्किल है

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

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

इस विधि के फायदे और नुकसान:
+ बहुत ही सरल अनुप्रयोग
+ उत्पादन के लिए सीमित
- परियोजना में "विदेशी" कोड का सम्मिलन
- उपयोग हमेशा संभव नहीं है
- विश्लेषण अनुभाग के निष्पादन समय को छोड़कर, कार्यक्रम के बारे में कोई जानकारी नहीं
- परिणामों का विश्लेषण मुश्किल हो सकता है

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

मुझे कहना होगा कि चुने हुए दृष्टिकोण की परवाह किए बिना, डेवलपर का मस्तिष्क डेवलपर का मुख्य उपकरण बना हुआ है। एक भी कार्यक्रम नहीं ( अभी तक (?) ) कहेंगे:
अरे, आपको प्रोजेक्ट / app.py फ़ाइल की लाइन 619 पर बकवास मिला ! उस कार्य को लूप से बाहर लाएं और आप खुश होंगे। और फिर भी, यदि आप कैशिंग का उपयोग करते हैं और सी में गणना फ़ंक्शन को फिर से लिखते हैं, तो प्रदर्शन औसत 18 गुना बढ़ जाएगा!

उपकरण क्या हैं

दो प्रकार के उपकरण हैं (वास्तव में, वर्गीकरण और शब्दावली के लिए बहुत अधिक विकल्प हैं, लेकिन हम खुद को दो तक सीमित करेंगे):

• सांख्यिकीय प्रोफाइलर
• नियतात्मक घटना-आधारित प्रोफाइलर

दुर्भाग्य से, मैं "निर्धारक" प्रोफाइलर के लिए रूसी में एक सुंदर नाम के साथ नहीं आ सका, इसलिए मैं "घटना" शब्द का उपयोग करूंगा। अगर कोई मुझे टिप्पणियों में सही करता है तो मैं आभारी रहूंगा।

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

पहली घटना प्रोफाइलर एक ही सत्तर के दशक के अंत में दिखाई दिया, यह यूनिक्स प्रोफ ओएस की उपयोगिता थी, जिसने सभी कार्यक्रम कार्यों का निष्पादन समय दिखाया। कुछ साल बाद (1982), gprof उपयोगिता दिखाई दी, जिसने फ़ंक्शन कॉल का ग्राफ़ प्रदर्शित करना सीखा।

सांख्यिकीय प्रोफाइलर

सांख्यिकीय प्रोफाइलर के संचालन का सिद्धांत सरल है: दिए गए (पर्याप्त रूप से छोटे) अंतराल पर, निष्पादित होने वाले वर्तमान अनुदेश के लिए एक संकेतक लिया जाता है और बाद में अध्ययन के लिए इस जानकारी ("नमूने") को बचाता है। यह इस तरह दिखता है:

यह देखा जा सकता है कि फ़ंक्शन बार () को फू () , बाज () और कुछ प्रकार के अनाम अनुदेशों की तुलना में लगभग ढाई गुना अधिक समय तक निष्पादित किया गया था ।

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

उदाहरण के लिए, यह आंकड़ा से देखा जा सकता है कि नामहीन फ़ंक्शन चयन में नहीं आया था।

विश्लेषण किए गए कार्यों के वास्तविक समय का मूल्यांकन करना भी मुश्किल है। उस स्थिति पर विचार करें जहां फ़ंक्शन फू () को जल्दी से निष्पादित किया जाता है, लेकिन बहुत बार कहा जाता है:

और एक ऐसी स्थिति जहां फू () फ़ंक्शन को बहुत लंबा समय लगता है, लेकिन केवल एक बार कहा जाता है:

सांख्यिकीय प्रोफाइलर का परिणाम दोनों मामलों में समान होगा।

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

सांख्यिकीय प्रोफाइलर के फायदे और नुकसान:
+ उत्पादन में डाला जा सकता है (विश्लेषण कार्यक्रम पर प्रभाव न्यूनतम है)
- हम कोड के बारे में सभी जानकारी से दूर हो जाते हैं (वास्तव में, केवल "हॉट स्पॉट")
- परिणाम की संभवतः गलत व्याख्या
- पर्याप्त आंकड़े एकत्र करने में लंबा समय लगता है
- कुछ विश्लेषण उपकरण

इवेंट प्रोफाइलर

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


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

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

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

अगले लेख में, हम अभ्यास मैनुअल प्रोफाइलिंग और सांख्यिकीय प्रोफाइलरों की जांच करेंगे। संपर्क में रहना =)