वहाँ एक से अधिक तरीका है यह।
Don't forget the no-profiler method.
अधिकांश प्रोफाइलर आप 1) समय (नमूने के बहुत सारे) के उच्च सांख्यिकीय परिशुद्धता की जरूरत मान, और 2) समस्या पहचान (कार्यों & कॉल-रेखांकन) की कम परिशुद्धता।
उन प्राथमिकताओं को उलट किया जा सकता है। अर्थात। समस्या सटीक मशीन पते पर स्थित हो सकती है, जबकि लागत परिशुद्धता नमूने की संख्या का एक कार्य है।
सबसे वास्तविक समस्याओं में कम से कम 10% की लागत है, जहां उच्च परिशुद्धता आवश्यक नहीं है।
उदाहरण: यदि कुछ प्रोग्राम आपके प्रोग्राम को 2 गुना तक ले रहा है, तो इसका मतलब है कि इसमें कुछ कोड है जो 50% खर्च करता है। यदि आप धीमी गति से कॉल स्टैक के 10 नमूने लेते हैं, तो कोड की सटीक रेखा लगभग 5 में मौजूद होगी। कार्यक्रम जितना बड़ा होगा, समस्या उतनी अधिक संभावना है कि समस्या कहीं मध्य-स्टैक कॉल हो।
यह काउंटर-इंट्यूविटिव है, मुझे पता है।
नोट: xPerf लगभग वहां है, लेकिन काफी नहीं (जहां तक मैं कह सकता हूं)। यह कॉल स्टैक के नमूने लेता है और उन्हें बचाता है - यह अच्छा है। यहां मुझे लगता है कि इसकी आवश्यकता है:
इसे केवल नमूने लेना चाहिए जब आप उन्हें चाहते हैं। जैसा कि है, आपको अप्रासंगिक लोगों को फ़िल्टर करना होगा।
स्टैक व्यू में यह विशिष्ट लाइनों या पतों को दिखाना चाहिए, जिन पर कॉल पूरे होते हैं, केवल पूरे कार्यों में नहीं। (शायद यह ऐसा कर सकता है, मैं ब्लॉग से नहीं बता सका।)
यदि आप तितली दृश्य प्राप्त करने के लिए क्लिक करते हैं, एक कॉल निर्देश, या पत्ती निर्देश पर केंद्रित, तो आपको सीपीयू अंश नहीं दिखाना चाहिए, लेकिन उस निर्देश वाले स्टैक नमूने का अंश दिखाना चाहिए। वह समय के एक अंश के रूप में उस निर्देश की लागत का सीधा उपाय होगा। (हो सकता है कि यह ऐसा कर सके, मैं नहीं बता सका।) तो, उदाहरण के लिए, भले ही कोई निर्देश फ़ाइल-ओपन या थ्रेड को निष्क्रिय करने वाले किसी अन्य व्यक्ति के लिए कॉल था, फिर भी यह दीवार घड़ी का समय खर्च करता है, और आपको इसकी आवश्यकता होती है जानते है कि।
नोट: मैंने सिर्फ ल्यूक स्टैकवाकर पर देखा, और वही टिप्पणी लागू होती है। मुझे लगता है कि यह सही रास्ते पर है लेकिन यूआई काम की जरूरत है।
जोड़ा गया: ल्यूकस्टैकवाल्कर को अधिक ध्यान से देखते हुए, मुझे डर है कि यह धारणा का शिकार हो जाता है कि कार्यों को मापने से बयानों का पता लगाने से अधिक महत्वपूर्ण है। तो कॉल स्टैक के प्रत्येक नमूने पर, यह फ़ंक्शन-स्तरीय समय की जानकारी अपडेट करता है, लेकिन यह लाइन-नंबर जानकारी के साथ करता है, प्रत्येक फ़ंक्शन में न्यूनतम और अधिकतम पंक्ति संख्याओं का ट्रैक रखता है, जो अधिक नमूने लेता है, उन लोगों के अलावा दूर। तो यह मूल रूप से सबसे महत्वपूर्ण जानकारी - पंक्ति संख्या की जानकारी फेंकता है। कारण यह महत्वपूर्ण है कि यदि आप किसी फ़ंक्शन को अनुकूलित करने का निर्णय लेते हैं, तो आपको यह जानना होगा कि इसमें किन लाइनों को काम की ज़रूरत है, और वे पंक्तियां ढेर के नमूने पर थीं (उन्हें छोड़ने से पहले)।
कोई यह ऑब्जेक्ट कर सकता है कि यदि लाइन नंबर की जानकारी बरकरार रखी गई तो यह भंडारण से जल्दी समाप्त हो जाएगी। दो जवाब 1) नमूने पर दिखाई देने वाली केवल कई रेखाएं हैं, और वे बार-बार दिखाई देती हैं। 2) इतने सारे नमूनों की आवश्यकता नहीं है - धारणा है कि माप की उच्च सांख्यिकीय परिशुद्धता जरूरी है, लेकिन कभी भी उचित नहीं माना जाता है।
मुझे संदेह है कि अन्य स्टैक नमूने, जैसे xPerf, समान समस्याएं हैं।
क्या मंच? जब मैं लिनक्स पर जी ++ के साथ काम कर रहा हूं तो मैं gprof का उपयोग करता हूं। –
मेरा प्रोग्राम विंडोज एक्सपी पर चलता है। – stanigator