[c#] डीबग बनाम रिलीज प्रदर्शन



3 Answers

ऐसा कोई लेख नहीं है जो प्रदर्शन प्रश्न के बारे में कुछ भी "सिद्ध" करता है। परिवर्तन के प्रदर्शन प्रभाव के बारे में एक अनुमान साबित करने का तरीका यह है कि इसे दोनों तरीकों से आजमाएं और यथार्थवादी-नियंत्रित नियंत्रित स्थितियों के तहत इसका परीक्षण करें।

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

और इसके अलावा, आप सार्थक परिणाम प्राप्त करने में सक्षम होंगे। "धीमा" व्यर्थ है क्योंकि यह स्पष्ट नहीं है कि यह एक माइक्रोसेकंड धीमा या बीस मिनट धीमा है या नहीं। "यथार्थवादी स्थितियों के तहत 10% धीमी" अधिक सार्थक है।

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

Question

मुझे निम्नलिखित अनुच्छेद का सामना करना पड़ा है:

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

स्रोत here और पॉडकास्ट here

क्या कोई मुझे माइक्रोसॉफ्ट आलेख में भेज सकता है जो वास्तव में यह साबित कर सकता है?

Googling " सी # डीबग बनाम रिलीज प्रदर्शन " ज्यादातर परिणाम देता है " डेबग बहुत प्रदर्शन हिट है ", " रिलीज अनुकूलित है ", और " उत्पादन में डीबग तैनात नहीं है "।




प्रदर्शन के संबंध में आपको एक बात ध्यान में रखना चाहिए और क्या डीबगर संलग्न है या नहीं, कुछ ऐसा जो हमें आश्चर्य से ले गया।

हमारे पास कोड का एक टुकड़ा था, जिसमें कई तंग लूप शामिल थे, जो हमेशा डीबग करने लगते थे, फिर भी अपने आप पर काफी अच्छा प्रदर्शन करते थे। दूसरे शब्दों में, कोई ग्राहक या ग्राहक जहां समस्याएं आ रही हैं, लेकिन जब हम डिबगिंग कर रहे थे तो यह गुड़ की तरह चल रहा था।

अपराधी एक Debug.WriteLine था। तंग लूपों में से एक में Debug.WriteLine , जो कुछ Debug.WriteLine तक एक डीबग सत्र से छोड़े गए हजारों लॉग संदेशों को थूकता था। ऐसा लगता है कि जब डीबगर संलग्न होता है और इस तरह के आउटपुट को सुनता है, तो इसमें ओवरहेड शामिल होता है जो प्रोग्राम को धीमा कर देता है। इस विशेष कोड के लिए, यह अपने आप पर 0.2-0.3 सेकंड रनटाइम के क्रम में था, और डीबगर संलग्न होने पर 30+ सेकंड।

सरल समाधान हालांकि, बस उन डीबग संदेशों को हटा दें जिनकी अब आवश्यकता नहीं थी।




एमएसडीएन सामाजिक से

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

जेआईटी कंपाइलर ऑप्टिमाइज़ेशन को अक्षम करने के लिए इस विशेषता का उपयोग करता है जो डिबगिंग को कठिन बना देगा। वे लोग जो लूप-इनवेरिएंट होस्टिंग जैसे कोड को स्थानांतरित करते हैं। चयनित मामलों में, यह प्रदर्शन में एक बड़ा अंतर कर सकता है। हालांकि आमतौर पर नहीं।

निष्पादन पते पर ब्रेकपॉइंट्स मैपिंग डीबगर का काम है। यह .pdb फ़ाइल और जेआईटी कंपाइलर द्वारा उत्पन्न जानकारी का उपयोग करता है जो कोड पता मैपिंग के लिए आईएल निर्देश प्रदान करता है। यदि आप अपना खुद का डीबगर लिखेंगे, तो आप आईसीओआरडीबगोड :: GetILToNativeMapping () का उपयोग करेंगे।

जेआईटी कंपाइलर अनुकूलन अक्षम होने के बाद मूल रूप से डीबग परिनियोजन धीमा हो जाएगा।




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

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




Related