हालत विभाजन

4

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

एक (पूर्णांक) विभाजन की वास्तविक लागत अपेक्षाकृत कम हो सकती है, खासकर आधुनिक डेस्कटॉप-क्लास प्रोसेसर पर। this PDF के मुताबिक, 32/32-बिट डिवीजन के आधुनिक (वुल्फडेल/नेहलेम/सैंडी ब्रिज) की लागत क्रमशः 14-23/17-28/20-28 चक्र हैं। इसलिए, यदि आप वास्तव में बहुत कुछ करते हैं, तो यह जोड़ सकता है। उस स्थिति में, यदि संभव हो तो समांतर (सदिश) विकल्पों में देखें।

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

स्रोत

2012-01-13 09:15:37 unwind

+0

+1, कम ब्रांचिंग का मतलब अधिक सरल और आसानी से समझने योग्य कोड है। –

+0

सामान्य रूप से अधिक सहमत नहीं हो सका, इस पर विचार कर रहा था क्योंकि मुझे लगता है कि यह वास्तव में कोड को भ्रमित नहीं करता है और इसे भारी रूप से निष्पादित किया जा रहा है। प्रोफाइलिंग बताएगा, धन्यवाद। – nantonop

2

यह निर्भर करता है।

क्या प्रदर्शन एक महत्वपूर्ण अनुप्रयोग में कोड है? यदि ऐसा है तो यह perf बुद्धिमान मदद कर सकता है। यदि अच्छी तरह से नहीं है तो मैं आमतौर पर पक्ष या पठनीयता पर गलती करता हूं और अगर अतिरिक्त कथन प्रस्तुत नहीं करता हूं।

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

आशा इस मदद करता है ...

स्रोत

2012-01-13 09:19:50 bstack

7

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

गति एक प्रमुख चिंता का विषय है:

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

(यह पुस्तकालय कोड के लिए अलग है, जाहिर है, लेकिन इन कुछ ही कदम आप एक लंबा रास्ता ले जाएगा।)

स्रोत

2012-01-13 09:42:37 sbi

+0

मैं सहमत हूं, लेकिन आप जिस बड़ी तस्वीर का वर्णन कर रहे हैं, वह मुझे आपके कोड में कुछ tweeking से बचने के लिए पर्याप्त कारण नहीं है जो perf में सुधार करेगा (यदि perf वह है जो आप चाहते हैं और यदि आप सुनिश्चित हैं कि यह वास्तव में सुधार होगा)। मैं यहाँ एक बड़े बदलाव के बारे में बात नहीं कर रहा हूं और मैं बाधाओं की स्थापना नहीं कर रहा हूं .. उसने कहा कि आपकी पोस्ट के लिए धन्यवाद और मुझे कहना होगा कि मैं सहमत हूं .. – nantonop

+1

@ नान्चोनोप: बिंदु यह है कि आप * सुनिश्चित नहीं हैं कि यह बेहतर होगा प्रदर्शन, और सभी संभावनाओं में यह नहीं होगा। –

+2

@nantonop: व्यर्थ अनुकूलन से बचने का कारण यह है कि ___ 1) ___ यह गिनती वाले स्पॉट को अनुकूलित करने के लिए आवश्यक संसाधनों को हटा देता है, और ___ 2) ___ यह [सूक्ष्म बग पेश कर सकता है] (http://stackoverflow.com/questions/8848167/ हालत-बनाम-डिवीजन # टिप्पणी-11,051,422)। – sbi

2

आप तो शाखाओं में आप आम मामले के लिए पहले की जांच कर सकता के साथ जाने का फैसला करते हैं। यह थोड़ा और अधिक पठनीय है और थोड़ा बेहतर प्रदर्शन के रूप में होना चाहिए।

if(uRatio <= 1) { 
    iNormVal = iVal; 
} 
else { 
    iNormVal = iVal/uRatio; 
}

आप एक अच्छे नाम है कि अभिव्यक्ति का परिणाम धारण के साथ एक स्थानीय चर जोड़ सकता है अधिक पठनीय होने के लिए।

unsigned int uSmallRatio = uRatio <= 1; 
if(uSmallRatio) { 
    iNormVal = iVal; 
} 
else { 
    iNormVal = iVal/uRatio; 
}

कंपाइलर इसे उसी मशीन कोड में पहले दृष्टिकोण के रूप में अनुकूलित कर सकता है। हालांकि मैं इसके बारे में निश्चित नहीं हूँ।

इसी तरह आप ऐसा कर सकता है लेकिन यह काफी नहीं है:

iNormVal = uRatio <= 1 ? iVal : iVal/uRatio;

अंत में एक और दृष्टिकोण होगा:

iNormVal = iVal; 
if(uRatio > 1) { /*explain why you do this so it won't be changed by somebody else*/ 
    iNormVal = iVal/uRatio; 
}

मुझे यकीन है कि वहाँ अन्य तरीकों पर विचार कर रहे हैं रहा हूँ।

सादर ...

स्रोत

2012-01-13 12:22:55

1

यदि खंड वास्तव में सबसे अधिक संभावना कार्यक्रम धीमी कर देगा। शाखाओं वास्तव में प्रदर्शन के लिए बुरा है क्योंकि आधुनिक प्रोसेसर pipelined हैं, और शाखाओं पूरी तरह से प्रभावी होने से पाइप लाइन को रोकने के। यह एक महत्वपूर्ण मुद्दा है कि branch prediction में काफी प्रयास किया जाता है, लेकिन यह इस मामले में मदद नहीं करेगा। यहां तक कि अगर भविष्यवाणी समय की सही 90% है, कि एक खाली पाइपलाइन समय है, जो एक पूर्णांक प्रभाग (expecially जब ध्यान में रखते हुए कि यदि खंड ही समय लगता है) की तुलना में बहुत खराब है के 10% का मतलब है।

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

स्रोत

2012-01-13 13:13:32

+0

आप निश्चित रूप से सिद्धांत में सही हैं। लेकिन यह शाखाकरण मशीन कोड के कुछ बाइट्स की संभावना है, इसलिए व्यवहार में इससे कोई फर्क नहीं पड़ता। _If_ आप इसे जानना चाहते हैं, आपको वास्तव में मापने और तुलना करने की आवश्यकता है (और ध्यान रखें कि यह मंच से मंच तक बहुत अलग हो सकता है)। लेकिन अगर आप इस जगह को भी जानते हैं तो यह वास्तव में केवल परेशानी का लायक है। – sbi

1

अधिकांश प्रदर्शन मुद्दे या तो विचारधारात्मक (आपने गलत तरीके से डिज़ाइन किया है), या एक सिद्ध धीमी एल्गोरिदम (दिए गए विकल्प) के कार्यान्वयन हैं।

इसके अलावा, प्रदर्शन में सुधार को विधानसभा स्तर पर होने जा रहे हैं, और मंच निर्भर हो जाएगा।

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

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

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

स्रोत

2012-01-13 16:02:42

हालत विभाजन

उत्तर

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