2013-08-12 4 views
5

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

टाइम कमांड दिखाता है कि प्रोग्राम को चलाने में लगभग 5 मिनट लगते हैं, और 5 मिनट के बारे में, उपयोगकर्ता सीपीयू समय में 4.5 मिनट लगते हैं।

सीपीयू प्रोफाइलर (दोनों जीसीसी प्रोफाइलर और गूगल परफेटोल) से पता चलता है कि फ़ंक्शन कॉल केवल CPU समय में कुल 60 सेकंड लेते हैं। मैंने सीपीयू समय के बजाय वास्तविक समय नमूना करने के लिए प्रोफाइलर का उपयोग करने की भी कोशिश की, और यह मुझे समान परिणाम देता है।

आई/ओ प्रोफाइलर (मैंने आईओएप का उपयोग किया) यह भी दिखाता है कि I/O केवल प्रोग्राम चलाने का लगभग 30 सेकंड लेता है।

तो मूल रूप से मेरे पास 3.5 मिनट (प्रोग्राम चलने का समय का सबसे बड़ा हिस्सा) के लिए अनिश्चित है, और मुझे विश्वास है कि जहां बाधा है।

मुझे क्या याद आया और मुझे यह पता चल जाएगा कि वह समय कहां जाता है?

+0

क्या कोड बहुसंख्यक है? क्या यह एक और प्रक्रिया शुरू करता है (उदा। 'फोर्क', 'exec' के साथ या उसके बिना)? –

+0

क्या आपने लिनक्स के अंतर्निर्मित पेर्फ को आजमाया था? 'perf रिकॉर्ड ' फिर 'perf रिपोर्ट'। – DanielKO

+1

जो आपने हमें दिया है, मेरा सबसे अच्छा अनुमान यह है कि आप प्रोफाइलर के आउटपुट को सही तरीके से नहीं पढ़ रहे हैं। Gprof/perf/strace (कम से कम शीर्ष 15 लाइनें या तो) के आउटपुट पोस्ट करें। – DanielKO

उत्तर

6

जैसा कि ओओ तिइब ने सुझाव दिया था, बस एक डीबगर में प्रोग्राम को तोड़ दें। जिस तरह से मैं इसे चलाता हूं, प्रोग्राम चल रहा है, आउटपुट विंडो पर स्विच करें, प्रोग्राम को बाधित करने के लिए Ctrl-C टाइप करें, जीडीबी विंडो पर वापस स्विच करें, "थ्रेड 1" टाइप करें ताकि मुख्य प्रोग्राम के संदर्भ में हो, और स्टैक ट्रेस देखने के लिए "बीटी" टाइप करें।

अब, स्टैक ट्रेस को देखें और इसे समझें, क्योंकि प्रोग्राम काउंटर पर निर्देश उस विशेष चक्र के लिए ज़िम्मेदार है, तो स्टैक पर हर कॉल है।

यदि आप इसे कुछ बार करते हैं, तो आप यह देखने जा रहे हैं कि बाधा के लिए वास्तव में कौन सी रेखा जिम्मेदार है। जैसे ही आप इसे दो (2) नमूनों पर देखते हैं, आपने इसे खींचा है। फिर इसे ठीक करें और इसे फिर से करें, अगली बाधा ढूंढें, और इसी तरह। आप आसानी से पाते हैं कि आपको इस तरह से भारी गति मिलती है।

< लौ>

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

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

छोटे बनाम नमूने की बड़ी संख्या के मुद्दे के बारे में क्या? ज्यादा बेहतर नहीं हैं? ठीक है, मान लीजिए कि आपके पास अनंत लूप है, या यदि अनंत नहीं है, तो यह आपके विचार से कहीं अधिक लंबा चलता है? क्या 1000 स्टैक नमूने इसे एक नमूना से बेहतर पाते हैं? (संख्या) यदि आप इसे डीबगर के तहत देखते हैं, तो आप जानते हैं कि आप लूप में हैं क्योंकि यह मूल रूप से 100% समय लेता है। यह कहीं ढेर पर है - जब तक आपको यह पता न लगे तब तक स्टैक को स्कैन करें। भले ही लूप केवल 50% या 20% समय लेता है, यह संभावना है कि प्रत्येक नमूना इसे देखेगा। तो, यदि आप कुछ देखते हैं तो आप दो नमूने के रूप में कम से कम छुटकारा पा सकते हैं, यह करने योग्य है। तो, 1000 नमूने आपको क्या खरीदते हैं?

शायद कोई सोचता है: "तो क्या होगा अगर हमें कोई समस्या या दो याद आती है? शायद यह काफी अच्छा है।" अच्छा, है ना? मान लीजिए कि कोड में तीन समस्याएं हैं जिनमें से 50% समय ले रहा है, क्यू 25% ले रहा है, और आर 12.5% ​​ले रहा है। अच्छी चीजें को ए कहा जाता है, यह आपको उस गति को दिखाता है यदि आप उनमें से एक को ठीक करते हैं, उनमें से दो, या उनमें से तीनों को ठीक करते हैं।

PRPQPQPAPQPAPRPQ original time with avoidable code P, Q, and R all mixed together 
RQQAQARQ   fix P   - 2 x speedup 
PRPPPAPPAPRP  fix Q   - 1.3 x " 
PPQPQPAPQPAPPQ fix R   - 1.14 x " 
RAAR    fix P and Q  - 4 x  " 
QQAQAQ   fix P and R  - 2.7 x " 
PPPPAPPAPP  fix Q and R  - 1.6 x " 
AA    fix P, Q, and R - 8 x speedup 

क्या इससे यह स्पष्ट हो जाता है कि "दूर जाने" वाले लोग वास्तव में क्यों चोट पहुंचाते हैं? सर्वोत्तम यदि आप किसी भी चीज को धीमा करते हैं तो आप कर सकते हैं।

यदि आप नमूने की जांच करते हैं तो उन्हें ढूंढना आसान होता है। पी आधे नमूनों पर है। यदि आप पी को ठीक करते हैं और फिर से करते हैं, तो क्यू नमूने के आधे भाग पर है। एक बार जब आप क्यू ठीक कर लेंगे, आर नमूने के आधे भाग पर है। फिक्स आर और आपको अपना 8x स्पीडअप मिला है। आपको वहां रुकने की ज़रूरत नहीं है। आप तब तक जारी रख सकते हैं जब तक आप वास्तव में ठीक करने के लिए कुछ भी नहीं ढूंढ पाते।

अधिक समस्याएं हैं, संभावित गतिशीलता अधिक है लेकिन आप किसी को भी याद नहीं कर सकते हैं। प्रोफाइलर्स (यहां तक ​​कि अच्छे वाले) के साथ समस्या यह है कि, आपको व्यक्तिगत नमूनों को देखने और पढ़ने का मौका नकारते हुए, वे उन समस्याओं को छिपाते हैं जिन्हें आपको ढूंढने की आवश्यकता है। More on all that. For the statistically inclined, here's how it works.

अच्छे प्रोफाइलर हैं। सर्वश्रेष्ठ दीवार-समय स्टैक नमूने हैं जो व्यक्तिगत लाइनों पर समावेशी प्रतिशत की रिपोर्ट करते हैं, जिससे आप हॉट-कुंजी के साथ नमूना चालू और बंद कर देते हैं। Zoom (wiki) ऐसा प्रोफाइलर है।

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

</लौ>

संबंधित मुद्दे