सबसे पहले, मुझे आश्चर्य है कि यह खबर है। दूसरा, समस्या यह नहीं है कि प्रोफाइलर्स खराब हैं, यह है कि कुछ प्रोफाइलर्स खराब हैं। लेखकों ने एक ऐसा बनाया है, जिसे वे मूल्यांकन करते हैं, उनमें से कुछ गलतियों से बचकर, वे अच्छा महसूस करते हैं। त्रुटियां कुछ लगातार myths about performance profiling की वजह से आम हैं।
लेकिन चलिए सकारात्मक बनें। एक speedup के लिए अवसर खोजने के लिए चाहता है, यह वास्तव में बहुत सरल है:
एक लगभग सार्वभौमिक गलती (है कि कागज शेयर) माप की सटीकता के साथ बहुत अधिक है, और स्थान की सटीकता के साथ पर्याप्त नहीं चिंतित होने की है। उदाहरण के लिए, यहां एक example of performance tuning है जिसमें प्रदर्शन समस्याओं की एक श्रृंखला की पहचान की गई और तय की गई, जिसके परिणामस्वरूप 43 गुना वृद्धि हुई। इसे ठीक करने से पहले प्रत्येक समस्या के आकार को सटीक रूप से जानना आवश्यक नहीं था, लेकिन इसके स्थान को जानने के लिए। प्रदर्शन ट्यूनिंग की एक घटना यह है कि समय को कम करके, एक समस्या को ठीक करना, शेष समस्याओं के प्रतिशत को बढ़ाता है, इसलिए उन्हें ढूंढना आसान होता है। जब तक कोई समस्या पाई जाती है और तय की जाती है, तो सभी समस्याओं को ढूंढने और ठीक करने के लक्ष्य की दिशा में प्रगति की जाती है। उन्हें आकार घटाने के क्रम में ठीक करने के लिए आवश्यक नहीं है, लेकिन उन्हें इंगित करना आवश्यक है।
माप की सांख्यिकीय सटीकता के विषय पर, अगर कॉल बिंदु स्टैक पर कुछ प्रतिशत एफ (जैसे 20%), और एन (जैसे 100) यादृच्छिक समय के नमूने लिया जाता है, तो नमूने की संख्या जो कॉल पॉइंट दिखाता है, एक द्विपक्षीय वितरण है, जिसका मतलब = एनएफ = 20, मानक विचलन = वर्ग (एनएफ (1-एफ)) = वर्ग (16) = 4. तो नमूने का प्रतिशत जो दिखाता है वह 20% +/- 4%। तो क्या यह सटीक है? वास्तव में नहीं, लेकिन समस्या मिली है? ठीक।
वास्तव में, बड़ी समस्या यह है कि प्रतिशत के मामले में, इसे कम करने के लिए कम नमूने की आवश्यकता होती है। उदाहरण के लिए, यदि 3 नमूने लिया जाता है, और उनमें से 2 पर एक कॉल पॉइंट दिखाई देता है, तो यह बहुत महंगा होने की संभावना है। (विशेष रूप से, यह बीटा वितरण का पालन करता है। यदि आप 4 वर्दी 0,1 यादृच्छिक संख्याएं उत्पन्न करते हैं, और उन्हें सॉर्ट करते हैं, तो तीसरे स्थान का वितरण उस कॉल पॉइंट के लिए लागत का वितरण होता है। इसका मतलब है (2 + 1)/(3 + 2) = 0.6, इसलिए उन नमूने दिए गए अपेक्षित बचत हैं।) निहित: और आपको प्राप्त होने वाले स्पीडअप कारक को अन्य वितरण, BetaPrime द्वारा नियंत्रित किया जाता है, और औसत औसत 4 है। तो यदि आप लेते हैं 3 नमूने, उनमें से 2 पर एक समस्या देखें, और उस समस्या को खत्म करें, औसतन आप कार्यक्रम को चार गुना तेज बना देंगे।
यह बहुत समय है कि हम प्रोग्रामर ने प्रोफाइलिंग के विषय पर हमारे सिर से कोबवे को उड़ा दिया।
अस्वीकरण - पेपर मेरे आलेख को संदर्भित करने में असफल रहा: डनलवे, "कॉल-स्टैक नमूना से प्राप्त निर्देश-स्तर लागत के साथ प्रदर्शन ट्यूनिंग", एसीएम सिग्प्लान नोटिस 42, 8 (अगस्त, 2007), पीपी 4-8। रोचक पढ़ने के लिए
+1। – daveb