अपवाद और प्रदर्शन

मैंने थोड़ा शोध पोस्ट करने का फैसला किया कि C ++ अपवाद समर्थन कोड के समग्र प्रदर्शन को कैसे प्रभावित करता है।



मेरे काम के अनुभव में विभिन्न एम्बेडेड सिस्टम के लिए कई वर्षों का विकास शामिल है, जहां कोड लिखते समय प्रदर्शन को लगातार ध्यान में रखा जाता है (वास्तविक समय सिस्टम जो बड़ी मात्रा में जानकारी की प्रक्रिया करते हैं - वहां कभी भी बहुत अधिक प्रोसेसर और मेमोरी गति नहीं होती है)। तदनुसार, इस वातावरण में, प्रोग्रामर को आमतौर पर एक अच्छा विचार है कि ओवरहेड क्या है (या नहीं) C ++ भाषा द्वारा प्रदान की गई एक विशेष सुविधा द्वारा किया जाता है। उदाहरण के लिए नेमस्पेस समर्थन - जो भी अतिरिक्त लागत नहीं; आरटीटीआई - उनके टाइप_इनफो के साथ वर्गों / संरचनाओं के नाम के साथ एक अतिरिक्त अनुभाग (परिणामस्वरूप बाइनरी आकार में वृद्धि हुई है, लेकिन यह कोड पीढ़ी को प्रभावित नहीं करता है); आदि हम देखेंगे कि कैसे ( सभी प्लेटफार्मों पर नहीं ) अपवाद समर्थन लागू किया गया है।



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



तो, चलो एक बहुत ही सरल पाठ कोड लेते हैं (नाम और स्थिरांक को विशेष रूप से चुना जाता है ताकि उन्हें संसाधित सूची में खोजना आसान हो):

struct AAAAA { int a; virtual void process(); AAAAA() { a = 1234; } virtual ~AAAAA() {} }; struct BBBBB : AAAAA { virtual void process(); BBBBB() { a = 5678; } virtual ~BBBBB() {} }; // forward declaration int bar(); int foo() { BBBBB b1; b1.a = bar(); b1.process(); BBBBB b2; b2.a = bar(); b2.process(); return b1.a + b2.a; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

सब कुछ बहुत सरल है - दो इनलाइन कंस्ट्रक्टर / डिस्ट्रक्टर, आभासी कार्यों के एक जोड़े, एक बाहरी फ़ंक्शन के लिए कॉल।



यहाँ अपवाद समर्थन के बिना परिणामी कोड है (परिणाम AStyle द्वारा संसाधित किया गया था)। एक शीट, लेकिन यह आवश्यक है:

 #line 1 "1.cpp" struct __T9639768; struct AAAAA; #line 9 struct BBBBB; struct __T9639768 { short d; short i; void (*f)(); }; #line 1 struct AAAAA { int a; struct __T9639768 *__vptr; }; #line 9 struct BBBBB { struct AAAAA __b_AAAAA; }; #line 17 extern int bar__Fv(void); extern int foo__Fv(void); #line 10 extern void process__5BBBBBFv(struct BBBBB *const); extern struct __T9639768 __vtbl__5AAAAA[3]; extern struct __T9639768 __vtbl__5BBBBB[3]; #line 19 int foo__Fv(void) { auto int __T9722792; auto struct BBBBB b1; auto struct BBBBB b2; #line 21 { { ((b1.__b_AAAAA).__vptr) = __vtbl__5AAAAA; ((b1.__b_AAAAA).a) = 1234; } ((b1.__b_AAAAA).__vptr) = __vtbl__5BBBBB; ((b1.__b_AAAAA).a) = 5678; } ((b1.__b_AAAAA).a) = (bar__Fv()); process__5BBBBBFv((&b1)); { { ((b2.__b_AAAAA).__vptr) = __vtbl__5AAAAA; ((b2.__b_AAAAA).a) = 1234; } ((b2.__b_AAAAA).__vptr) = __vtbl__5BBBBB; ((b2.__b_AAAAA).a) = 5678; } ((b2.__b_AAAAA).a) = (bar__Fv()); process__5BBBBBFv((&b2)); { __T9722792 = ((((b1.__b_AAAAA).a)) + (((b2.__b_AAAAA).a))); { ((b2.__b_AAAAA).__vptr) = __vtbl__5BBBBB; { { ((b2.__b_AAAAA).__vptr) = __vtbl__5AAAAA; } } } { ((b1.__b_AAAAA).__vptr) = __vtbl__5BBBBB; { { ((b1.__b_AAAAA).__vptr) = __vtbl__5AAAAA; } } } return __T9722792; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

आप स्पष्ट रूप से देख सकते हैं कि प्रत्येक ऑब्जेक्ट "निर्माण" कैसे किया जाता है, कैसे व्यवहार्य / विरासत को लागू किया जाता है, कि निर्माता / विध्वंसक अभी भी इनलाइन हैं, और सी कंपाइलर में अभी भी इस कोड को प्रभावी ढंग से अनुकूलित करने के लिए सभी जानकारी है। यह भी ध्यान दें कि परिणामस्वरूप सी-कोड में 72 लाइनें और लगभग 1.6kB लगती हैं।



अब उसी स्रोत को अपवाद समर्थन के साथ प्रसारित किया जाता है।



परिणाम यहां देखें: 253 लाइनों और 8.5 kB के सी-समतुल्य । यहां मैं इसे पोस्ट नहीं करूंगा, मैं खुद को मुख्य समारोह (पूर्व में int foo()



) के साथ कुछ बिंदुओं की टिप्पणियों तक सीमित करूंगा:

 int foo__Fv(void) { static struct __T9641460 __T9653776[2] = {{((void (*)())__dt__5BBBBBFv),((unsigned short)0U),((unsigned short)65535U),((unsigned char)0U)},{((void (*)())__dt__5BBBBBFv),((unsigned short)1U),((unsigned short)0U),((unsigned char)0U)}}; auto void *__T9731464[2]; auto int __T9733536; auto struct #line 20 __T9643156 __T9734356; auto struct BBBBB b1; auto struct BBBBB b2; (__T9734356.next) = __curr_eh_stack_entry; __curr_eh_stack_entry = (&__T9734356); (__T9734356.kind) = ((unsigned char)1U); (((__T9734356.variant).function).regions) = ((struct __T9641460 *)__T9653776); (((__T9734356.variant).function).obj_table) = ((void **)__T9731464); ((( #line 25 __T9734356.variant).function).saved_region_number) = __eh_curr_region; __eh_curr_region = ((unsigned short)65535U); #line 21 __ct__5BBBBBFv((&b1)); (((void **)__T9731464)[0U]) = ((void *)(&b1)); __eh_curr_region = ((unsigned short)0U); ((b1.__b_AAAAA).a) = (bar__Fv()); process__5BBBBBFv((&b1)); __ct__5BBBBBFv((&b2)); (((void **)__T9731464)[1U]) = ((void *)(&b2)); __eh_curr_region = ((unsigned short)1U); ((b2.__b_AAAAA).a) = (bar__Fv()); process__5BBBBBFv((&b2)); { __T9733536 = ((((b1.__b_AAAAA).a)) + (((b2.__b_AAAAA).a))); __eh_curr_region = ((unsigned short)0U); __dt__5BBBBBFv((&b2), 2); __eh_curr_region = ((unsigned short)65535U); __dt__5BBBBBFv((&b1), 2); { __eh_curr_region = ((((__T9734356.variant).function).saved_region_number)); __curr_eh_stack_entry = #line 29 ((__T9734356.next)); return __T9733536; } } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

प्रमुख परिवर्तन:

• निर्माता अब इनलाइन नहीं हैं (__ct__5BBBBBBFv कॉल दिखाई दिए हैं),
• विध्वंसक (__dt__5BBBBBBFv) के साथ समान स्थिति,
• कोड अब यह पता लगाता है कि किन वस्तुओं का निर्माण पहले ही हो चुका है (या पहले ही हटा दिया गया है) और जो अभी तक नहीं है - चूंकि आपको यह जानना होगा कि किन वस्तुओं के विध्वंसक हैं जिन्हें आप अपवाद कहते हैं, तो
• कंस्ट्रक्टर / विध्वंसक का कोड और अधिक जटिल हो गया है (फ़ंक्शन __dt__5BBBBBBFv / ct__5BBBBBFv, लिंक देखें),

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



वह यह है: केवल अपवादों के लिए समर्थन को चालू करने से अंतिम बाइनरी फ़ाइल की मात्रा में वृद्धि हुई है, और सभी कार्यों में एक मंदी है जिसके भीतर वस्तुओं का निर्माण किया जाता है (सबसे तुच्छ लोगों के अपवाद के साथ)।



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



पुनश्च: यह सब, ज़ाहिर है, इसका मतलब यह नहीं है कि "अपवाद बुरे हैं!" या "अपवादों के बजाय रिटर्न कोड का उपयोग करें!"। बस हर उपकरण अपने कार्य के लिए अच्छा है।

PPS: एम्बेडेड विकास में त्रुटि स्थितियों से निपटने के लिए समर्थन, निश्चित रूप से वहाँ है और सक्रिय रूप से उपयोग किया जाता है। वह आमतौर पर C ++ अपवादों का उपयोग नहीं करता है, यह एक अलग लेख का विषय है।