👨🏻‍🏫 😶 🛁 संरचनाएं बनाम कक्षाएं 🤱 ✈️ 🛄

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

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

PS मैंने Xcode 10.3 पर एक लेख पर काम करना शुरू किया और मैंने Xcode 11 के साथ इसकी गति की तुलना करने की कोशिश करने के बारे में सोचा, लेकिन फिर भी लेख दो अनुप्रयोगों की तुलना करने के बारे में नहीं है, बल्कि हमारे अनुप्रयोगों की गति के बारे में है। मुझे कोई संदेह नहीं है कि कार्यों का रनटाइम घट जाएगा, और जो खराब रूप से अनुकूलित किया गया है वह तेजी से हो जाएगा। नतीजतन, मैंने नई स्विफ्ट 5.1 का इंतजार किया और अभ्यास में परिकल्पनाओं का परीक्षण करने का फैसला किया। अच्छा पढ़ा है।

परीक्षण 1: संरचनाओं और कक्षाओं पर तुलना की तुलना करें

मान लीजिए कि हमारे पास एक वर्ग है, और हम इस वर्ग की वस्तुओं को एक सरणी में रखना चाहते हैं, एक सरणी पर सामान्य क्रिया इसके माध्यम से लूप करना है।

किसी सरणी में, जब इसमें कक्षाओं का उपयोग करते हैं और इसके माध्यम से चलने की कोशिश करते हैं, तो ऑब्जेक्ट की लिंक की संख्या पूरी होने के बाद लिंक की संख्या बढ़ जाती है।

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

अंजीर। 1: संरचनाओं और कक्षाओं के आधार पर सरणियों से एक चर प्राप्त करने की तुलना

टेस्ट 2. तुलना ContiguousArray बनाम ऐरे

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

आइए निम्नलिखित मामलों के लिए प्रदर्शन की जाँच करें:

ContiguousArray मान प्रकार के साथ एक संरचना का भंडारण
ContiguousArray स्ट्रिंग के साथ संरचना जमा करना
ContiguousArray मूल्य वर्ग के साथ भंडारण वर्ग
ContiguousArray स्ट्रिंग के साथ भंडारण वर्ग
मूल्य प्रकार के साथ अर्रे भंडारण संरचना
स्ट्रिंग स्टोरेज के साथ ऐरे स्टोरिंग स्ट्रक्चर
मूल्य प्रकार के साथ एरियर भंडारण वर्ग
स्ट्रिंग स्टोरिंग के साथ ऐरे स्टोरिंग करें

चूंकि परीक्षण के परिणाम (परीक्षण: इनलाइन ऑप्टिमाइज़ेशन के साथ किसी फ़ंक्शन में जाना बंद हो गया है, इनलाइन ऑप्टिमाइज़ेशन के साथ फ़ंक्शन को पास करना, तत्वों को हटाना, तत्वों को जोड़ना, एक लूप में एक तत्व तक अनुक्रमिक पहुंच) में बड़ी संख्या में परीक्षण शामिल होंगे (प्रत्येक 5 परीक्षणों के 8 सेकंड के लिए) , मैं सबसे महत्वपूर्ण परिणाम दूंगा:

यदि आप किसी फ़ंक्शन को कॉल करते हैं और इसके लिए एक सरणी पास करते हैं, तो इनलाइन बंद कर देते हैं, तो ऐसी कॉल बहुत महंगी होगी (संदर्भ स्ट्रिंग के आधार पर कक्षाओं के लिए, यह 20,000 गुना धीमी है, मूल्य के आधार पर वर्गों के लिए, इनलाइन ऑप्टिमाइज़र बंद होने के साथ प्रकार 60,000 गुना बदतर है) ।
यदि अनुकूलन (इनलाइन) आपके लिए काम करता है, तो गिरावट की उम्मीद केवल 2 बार की जानी चाहिए, यह निर्भर करता है कि किस प्रकार के डेटा को किस सरणी में जोड़ा गया है। एकमात्र अपवाद मूल्य प्रकार था, जो कॉन्टिग्रसअरे में पड़ी संरचना में लिपटे हुए था - समय की गिरावट के बिना।
निष्कासन - संदर्भ सरणी और सामान्य के बीच प्रसार लगभग 20% (सामान्य एरे के पक्ष में) था।
परिशिष्ट - जब कक्षाओं में लिपटे वस्तुओं का उपयोग करते हैं, तो ContiguousArray में समान वस्तुओं के साथ Array की तुलना में लगभग 20% अधिक तेजी थी, जबकि Array तेजी से संरचनाओं के साथ ContiguousArray की तुलना में काम कर रहा था।
सरणी तत्वों का उपयोग जब संरचनाओं से रैपर का उपयोग किया जाता है, तो कॉन्टिग्रसएयर्रे (लगभग 500 गुना तेज) सहित कक्षाओं में किसी भी रैपर की तुलना में तेजी से होता है।

ज्यादातर मामलों में, वस्तुओं के साथ काम करने के लिए नियमित सरणियों का उपयोग करना अधिक कुशल है। इससे पहले, हम आगे उपयोग करते हैं।

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

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

टेस्ट 3: बड़े वर्गों के भंडारण के स्ट्रक्चर्स और क्लासेस के प्रदर्शन की तुलना करें

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

अंजीर। 2: "संरचना का उपयोग बंद करो" लेख से संरचनाओं और कक्षाओं का प्रदर्शन

परीक्षण के परिणामों में अंतर नगण्य हैं।

टेस्ट 4: सामान्य के बिना कार्य स्वीकार करना, प्रोटोकॉल, और कार्य

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

अंजीर। 3: विशिष्ट सामान्य कार्य

मैंने दो कार्यों का परीक्षण करने का निर्णय लिया: पहले में, जेनेरिक डेटा प्रकार घोषित किया गया है, दूसरा सिर्फ प्रोटोकॉल को स्वीकार करता है। स्विफ्ट 5.1 प्रोटोकॉल के नए संस्करण में, यह जेनेरिक (स्विफ्ट 5.1 से पहले प्रोटोकॉल 2 गुना धीमा था) की तुलना में थोड़ा तेज है, हालांकि ऐप्पल के अनुसार यह चारों ओर का दूसरा रास्ता होना चाहिए, लेकिन जब यह एक सरणी से गुजरने की बात आती है, तो हमें पहले से ही टाइप करना होगा, जो धीमा हो जाता है सामान्य (लेकिन वे अभी भी महान हैं, क्योंकि वे प्रोटोकॉल से अधिक तेज़ हैं):

अंजीर। 4: जेनेरिक और प्रोटोकॉल मेजबान कार्यों की तुलना।

परीक्षण 5: मूल विधि और मूल निवासी की कॉल की तुलना करें, और एक ही समय में ऐसी कॉल के लिए अंतिम वर्ग की जांच करें

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

अंजीर। 5: प्रेषण परीक्षण के लिए कक्षा विधि कॉल

उपरोक्त परीक्षण से कई निष्कर्ष निकाले जा सकते हैं: माता-पिता की कक्षाओं का वर्ग जितना बड़ा होगा, वह उतना ही धीमा काम करेगा, और यह कि गति में अंतर इतना छोटा है कि इसे सुरक्षित रूप से उपेक्षित किया जा सकता है, सबसे अधिक संभावना कोड अनुकूलन इसे बना देगा ताकि गति में कोई अंतर न हो। इस उदाहरण में, अंतिम वर्ग संशोधक का एक फायदा नहीं है, इसके विपरीत, वर्ग का काम भी धीमा है, संभवतः इस तथ्य के कारण कि यह वास्तव में तेजी से कार्य नहीं करता है।

परीक्षण 6: एक नियमित वर्ग चर के खिलाफ अंतिम संशोधक के साथ एक चर बुला

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

अंजीर। 6: अंतिम चर को बुलाओ

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

टेस्ट 7: संरचनाओं के लिए बहुरूपता और प्रोटोकॉल की समस्या। या एक अस्तित्ववादी कंटेनर का प्रदर्शन

समस्या: यदि हम एक प्रोटोकॉल लेते हैं, जो इस प्रोटोकॉल से विरासत में मिली एक निश्चित विधि और कई संरचनाओं का समर्थन करता है, तो मूल प्रोटोकॉल द्वारा एकजुट एक सरणी में विभिन्न मूल्यों के साथ संरचनाओं को रखने पर हमारे संकलक क्या सोचेंगे?

वारिस में पूर्वनिर्धारित विधि को कॉल करने की समस्या को हल करने के लिए, प्रोटोकॉल गवाह तालिका तंत्र का उपयोग किया जाता है। यह शेल संरचनाओं का निर्माण करता है जो आवश्यक तरीकों का संदर्भ देते हैं।

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

चित्रा 7. एक सरणी के प्रदर्शन की तुलना जो किसी वस्तु का लिंक बनाता है और जिसमें यह शामिल है

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

अपनी परियोजनाओं को अनुकूलित करने के लिए थोड़ा सा सिद्धांत

निम्नलिखित कारक संरचनाओं के प्रदर्शन को प्रभावित कर सकते हैं:

जहाँ इसके चर संग्रहित होते हैं (ढेर / ढेर);
गुणों के लिए संदर्भ गिनती की आवश्यकता;
शेड्यूलिंग के तरीके (स्थिर / गतिशील);
कॉपी-ऑन-लिखने का उपयोग केवल डेटा संरचनाओं द्वारा किया जाता है जो हुड के नीचे संरचनाओं (स्ट्रिंग, सरणी, सेट, शब्दकोश) के लिए संदर्भ प्रकार हैं।

यह तुरंत स्पष्ट करने के लायक है कि सभी का सबसे तेज़ वे ऑब्जेक्ट होंगे जो स्टैक में गुणों को संग्रहीत करते हैं, मेडिकल परीक्षा की स्थैतिक विधि के साथ संदर्भ गिनती का उपयोग नहीं करते हैं।

संरचनाओं की तुलना में थान कक्षाएं खराब और खतरनाक हैं

हम हमेशा अपनी वस्तुओं की नकल को नियंत्रित नहीं करते हैं, और यदि हम ऐसा करते हैं, तो हम बहुत अधिक प्रतियां प्राप्त कर सकते हैं जिन्हें प्रबंधित करना मुश्किल होगा (हमने उस परियोजना में ऑब्जेक्ट बनाए जो दृश्य बनाने के लिए जिम्मेदार हैं, उदाहरण के लिए)।

वे संरचनाओं के रूप में तेज़ नहीं हैं।

यदि हमारे पास किसी ऑब्जेक्ट का लिंक है, और हम अपने एप्लिकेशन को एक बहु-थ्रेडेड शैली में प्रबंधित करने का प्रयास कर रहे हैं, तो हम रेस कंडीशन प्राप्त कर सकते हैं जब हमारी वस्तु का उपयोग दो अलग-अलग स्थानों से किया जाता है (जो इतना मुश्किल नहीं है, क्योंकि Xcode के साथ बनाया गया एक प्रोजेक्ट हमेशा थोड़ा धीमा होता है, स्टोर संस्करण की तुलना में)।

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

यदि हम अपनी वस्तुओं (लिंक) पर उपरोक्त सभी क्रियाएं करते हैं, तो अप्रत्याशित गतिरोध की संभावना अधिक है।

इसकी वजह से कोड जटिलता बढ़ रही है।

अधिक कोड = अधिक बग, हमेशा!

निष्कर्ष

मैंने सोचा था कि इस लेख में निष्कर्ष केवल आवश्यक हैं, क्योंकि मैं समय-समय पर लेख नहीं पढ़ना चाहता हूं, और अंकों की एक समेकित सूची बस आवश्यक है। परीक्षणों के तहत लाइनों को समेटते हुए, मैं निम्नलिखित बातों पर प्रकाश डालना चाहता हूं:

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

संदर्भ:
medium.com/@vhart/protocols-generics-and-existential-containers-wait-what-e2e698262ab1
developer.apple.com/videos/play/wwdc2016/416
developer.apple.com/videos/play/wwdc2015/409
developer.apple.com/videos/play/wwdc2016/419
medium.com/commencis/stop-using-structs-e1be9a86376f
स्रोत कोड का परीक्षण करें

संरचनाएं बनाम कक्षाएं