2009-04-20 17 views
274

संभव डुप्लिकेट:
Is there any significant difference between using if/else and switch-case in C#?"स्विच() केस" से "तेज" है?

मैं एक पूर्व पास्कल पुरुष हूँ, वर्तमान में सीखने सी #। मेरा प्रश्न निम्न है:

क्या कोड स्विच करने से तेज़ नीचे है?

int a = 5; 

if (a == 1) 
{ 
    .... 
} 
else if(a == 2) 
{ 
    .... 
} 
else if(a == 3) 
{ 
    .... 
} 
else if(a == 4) 
{ 
    .... 
} 
else 
    .... 

और स्विच:

int a = 5; 

switch(a) 
{ 
    case 1: 
     ... 
     break; 

    case 2: 
     ... 
     break; 

    case 3: 
     ... 
     break; 

    case 4: 
     ... 
     break; 

    default: 
     ... 
     break; 


} 

कौन सा तेज है?

मैं पूछ रहा हूं, क्योंकि मेरे कार्यक्रम में एक समान संरचना है (कई, कई "अगर" कथन)। क्या मुझे उन्हें स्विच में बदलना चाहिए?

+65

मुझे यह नोट करने के लिए मजबूर होना पड़ता है कि यदि आपके कोड में इनमें से बहुत से संरचनाएं हैं तो आप अपने डिज़ाइन में बहुरूपता का उपयोग कर सकते हैं। –

+4

देखें http://stackoverflow.com/questions/445067/if-vs-switch-speed –

+0

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

उत्तर

466

कुछ ही वस्तुओं के लिए, अंतर छोटा है। यदि आपके पास कई आइटम हैं तो आपको निश्चित रूप से स्विच का उपयोग करना चाहिए।

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

+75

सच है, लेकिन यदि एक और-अगर-श्रृंखला के साथ आप शर्तों को ऑर्डर कर सकते हैं कि वे कितने संभावित हैं। –

+58

हां, लेकिन पहले 4-5 मामलों को धीरे-धीरे धीमे लोगों के लिए 100% घटनाओं को पकड़ना पड़ता है। – Guffa

+21

क्या अधिकांश आधुनिक कंपाइलर्स गहरे ऑप्टिमाइज़ नहीं करना चाहिए अगर/अन्य यदि/तो अगर कोई स्विच/कूद तालिका के रूप में निर्णय लेता है? जिसका मतलब है; इससे कोई फर्क नहीं पड़ता, संकलक इसे अनुकूलित करने जा रहा है, क्यों न केवल सबसे पठनीय कोड लिखते हैं? –

5

परीक्षण करने में कठिनाई नहीं होनी चाहिए, एक फ़ंक्शन बनाएं जो स्विच या इफेलसे 5 नंबरों के बीच हो, उस फ़ंक्शन में एक रैंड (1,5) फेंक दें और लूप करें जो इसे समय के साथ कुछ बार करें।

3

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

मैं यहां सामान्य मामले के बारे में बात कर रहा हूं। 5 प्रविष्टियों के लिए, ifs के लिए किए गए परीक्षणों की औसत संख्या 2.5 से कम होनी चाहिए, यह मानते हुए कि आप आवृत्ति के अनुसार शर्तों का ऑर्डर करते हैं। मुश्किल से एक बहुत तंग पाश में जब तक घर लिखने के लिए एक बाधा।

7

मैं कहूंगा कि स्विच जाने का रास्ता है, यह तेज़ और बेहतर अभ्यास दोनों है।

कई लिंक हैं (http://www.blackwasp.co.uk/SpeedTestIfElseSwitch.aspx) जो दो की तुलना में बेंचमार्क परीक्षण दिखाते हैं।

5

स्विच आमतौर पर आईएफएस की एक लंबी सूची से तेज़ होता है क्योंकि संकलक एक कूद तालिका उत्पन्न कर सकता है। सूची जितनी लंबी होगी, बेहतर कथन कथन की श्रृंखला से बेहतर होगा।

+2

नोएट कि कूद-तालिका केवल संगत मूल्यों के लिए लागू होती है (आईआईआरसी)। संकलक के लिए जटिल गैर-संगत विकल्पों के लिए कूद-तालिकाओं और ब्रेक के मिश्रण को उत्सर्जित करना असामान्य नहीं है। –

19

this performance evaluation विश्वास, स्विच केस तेज है।

परिणाम बताते हैं कि स्विच बयान करता है, तो-और कुछ-यदि सीढ़ी से निष्पादित करने के लिए तेजी से होता है:

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

3

switch आमतौर पर कंपाइलर द्वारा लुकअप टेबल में अनुवाद किया जाता है, यदि संभव हो तो। तो एक मनमानी मामले की तलाश ओ (1) है, वास्तव में आप जो चाहते हैं उसे ढूंढने से पहले कुछ मामला तुलना करने की बजाय।

इसलिए कई मामलों में if/else if श्रृंखला धीमी हो जाएगी।आवृत्ति के आधार पर जिसके साथ आपके मामलों को मारा जा रहा है, इससे कोई फर्क नहीं पड़ता है।

2

लघु जवाब: स्विच बयान है जल्दी

, जिसे आप दो तुलना की जरूरत है सही खंड को पाने के लिए औसतन (जब आपके उदाहरण कोड चलाने) अगर बयान।

स्विच स्टेटमेंट तुलना की औसत संख्या आपके पर कितने अलग-अलग मामलों के बावजूद होगी। संकलक/वीएम संकलन समय पर संभावित विकल्पों की "लुकअप टेबल" बना देगा।

वर्चुअल मशीन यदि आप इस कोड को अक्सर चलाते हैं तो उसी तरह के कथन को अनुकूलित कर सकते हैं?

11

विचार करने की एक और बात: क्या यह वास्तव में आपके आवेदन की बाधा है? बहुत दुर्लभ मामले हैं जब इस तरह के अनुकूलन वास्तव में आवश्यक है। अधिकांश समय आप अपने एल्गोरिदम और डेटा संरचनाओं पर पुनर्विचार करके बेहतर गतिशील तरीके प्राप्त कर सकते हैं।

4

स्विच के प्रदर्शन लाभ (जो अपेक्षाकृत मामूली हैं, लेकिन ध्यान देने योग्य हैं) की तुलना में कहीं अधिक महत्वपूर्ण है पठनीयता समस्याएं हैं।

मैं एक के लिए आईईएस की श्रृंखला की तुलना में इरादे और शुद्ध सफेद स्थान पर एक स्पष्ट कथन को स्पष्ट रूप से स्पष्ट करता हूं।

147

आपको परवाह क्यों है?

उस समय 99.99%, आपको परवाह नहीं करनी चाहिए।

माइक्रो-ऑप्टिमाइज़ेशन के इस प्रकार आपके कोड के प्रदर्शन को प्रभावित करने की संभावना नहीं हैं।

इसके अलावा, अगर आपको परवाह करने की आवश्यकता है, तो आपको अपने कोड पर प्रदर्शन प्रोफाइलिंग करना चाहिए। एक मामले में स्विच केस के बीच प्रदर्शन अंतर का पता लगाना और यदि कोई अन्य ब्लॉक छोटा हो जाएगा।

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

+45

मुझे लगता है कि 100% समय, आपको परवाह नहीं करनी चाहिए। – Naveen

+78

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

+5

ओह, मैं मानता हूं कि आपको हमेशा पठनीयता और रखरखाव की परवाह करनी चाहिए। एक विशाल स्विच/केस ब्लॉक को फिर से लिखने का सही तरीका शायद बहुरूपता है (जो संयोगवश, शायद थोड़ा धीमा है, लेकिन आपको परवाह नहीं करना चाहिए)। मैक्रो-ऑप्टिमाइज़ेशन (अच्छा डिज़ाइन) माइक्रो-ऑप्टिमाइज़ेशन (तेज़ कथन) से हमेशा बेहतर होता है। – Wedge

1

के बाद से switch बयान अपने if/else श्रृंखला के रूप में लेकिन एक और अधिक सीमित, औपचारिक ढंग से एक ही मंशा व्यक्त करता है, अपने पहले अनुमान होना चाहिए कि संकलक के बाद से इसके बारे में अधिक निष्कर्ष आकर्षित कर सकते हैं, यह बेहतर अनुकूलन करने के लिए सक्षम हो जाएगा आपके कोड पर रखी गई स्थितियां (यानी केवल एक राज्य संभवतः सत्य हो सकता है, तुलना की जाने वाली मान एक आदिम प्रकार है, आदि) यह एक बहुत ही सुरक्षित सामान्य सत्य है जब आप रनटाइम प्रदर्शन के लिए दो समान भाषा संरचनाओं की तुलना कर रहे हैं।

4

मुझे यकीन नहीं है, लेकिन मुझे लगता है कि आप प्रोग्रामिंग भाषा के आधार पर एक या दूसरे परिवर्तनों की गति पर विश्वास करते हैं।

मैं आमतौर पर स्विच का उपयोग करना पसंद करता हूं।इस तरह कोड पढ़ने के लिए सरल है।

1

देख http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.switch%28VS.71%29.aspx

स्विच बयान मूल रूप से एक को देखने तालिका यह विकल्प जो जाना जाता है है और अगर बयान बूलियन प्रकार की तरह है। मेरे अनुसार स्विच और अगर-वही हैं लेकिन तर्क स्विच के लिए और बेहतर मदद कर सकते हैं। जबकि अगर-पढ़ने में भी समझने में मदद मिलती है।

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