2013-08-27 6 views
9

मेरे पास एक ऐसा एप्लिकेशन है जिसमें 4 धागे हैं। प्रत्येक धागा वास्तव में टाइमर है और विशिष्ट अंतराल में एक अलग नौकरी करता है। ये धागे Console.Writeline का उपयोग करके अपने लॉग दिखाते हैं। इस एप्लिकेशन में प्रदर्शन बहुत महत्वपूर्ण है। मैं जानना चाहता था कि Console.Writeline को हटाने से इस एप्लिकेशन के प्रदर्शन को ट्यून किया जाएगा या नहीं?कंसोल। प्रदर्शन पर राइटलाइन प्रभाव

+5

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

+0

दरअसल यह –

+0

डिबगिंग की निगरानी के लिए नहीं है, आपको यह क्यों पूछना है कि आप इसे आजमा सकते हैं, यह मुश्किल नहीं है ... उत्पादन वातावरण (प्रदर्शन के महत्व पर विचार करने के लिए), आपको केवल सबसे आवश्यक डीबग संदेश रखना चाहिए। –

उत्तर

8

वहाँ प्रदर्शन के संबंध में Console.WriteLine साथ दो मुद्दों हो सकता है:

  1. आईओ आम तौर पर एक "तेज" आपरेशन नहीं है।

  2. लिखने के लिए कॉल सिंक्रनाइज़ किए गए हैं, यानी यदि दो धागे लिखना चाहते हैं, तो उनमें से एक लिखितलाइन पर लिखने के लिए दूसरे को लिखने के लिए इंतजार कर रहा है। MSDN on console से:

आई/ओ आपरेशन है कि इन धाराओं का उपयोग सिंक्रनाइज़ किए जाते हैं, जिसका अर्थ है कि एक से अधिक थ्रेड से पढ़ सकते हैं, या करने के लिए, स्ट्रीम लिख।

यह कहा गया कि कंसोल पर बिताए गए समय को समझने का एकमात्र तरीका है। राइटलाइन का आपके विशिष्ट अनुप्रयोग के प्रदर्शन पर असर पड़ रहा है। अन्यथा यह समयपूर्व अनुकूलन है।

2

यदि यह डीबगिंग उद्देश्य के लिए है, तो आपको इसका उपयोग करना चाहिए: Debug.WriteLine, क्योंकि इन्हें रिलीज़ संस्करण में शामिल नहीं किया गया है।

+2

देखें मुझे नहीं लगता कि यह ओपी के प्रश्न का उत्तर कैसे देता है। आप एक ऐप के रिलीज़ संस्करण से लॉगिंग आउटपुट भी इकट्ठा करना चाहते हैं, और वैसे भी यह बिंदु के बगल में है कि लॉगिंग का उद्देश्य क्या है। – millimoose

+0

आप Trace.WriteLine का उपयोग कर सकते हैं, http://stackoverflow.com/questions/179868/trace-vs-debug-in-net-bcl –

7

हां, कंसोल निष्पादित करना। राइटलाइन में मापने योग्य समय लगता है।

कंसोल को हटा रहा है। राइटलाइन कॉल या डेटा लिखने वाले बफर्ड पृष्ठभूमि थ्रेड में इसे बदलकर वास्तव में एप्लिकेशन को तेज़ कर देगा।

हालांकि आपके बाजरे उपयोग में ओएस के आधार पर भिन्न हो सकते हैं।

+0

पृष्ठभूमि थ्रेड पर कतार के साथ एकमात्र समस्या यह है कि लॉगिंग नहीं है अब सटीक और धागे पहले ही समाप्त हो चुके हैं, और फिर भी लॉगिंग कंसोल पर लिखी गई है। –

+0

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

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