प्रोसेसर संसाधनों के संदर्भ में सॉफ़्टवेयर मुद्रास्फीति - एप्लिकेशन के नए संस्करण कभी-कभी पुराने लोगों की तुलना में बहुत धीमे क्यों होते हैं?

प्रस्तावना

यह एक नियमित गुरुवार की रात थी। मैं काम से लौट आया, लैपटॉप पर बैठ गया, इसे चालू किया, स्काइप शुरू किया और अंत में पूरी तरह से पूरी तरह से बूट करने के लिए आदतन इंतजार करना शुरू कर दिया। और फिर मैंने अचानक सोचा - इसे लोड करने में इतना समय क्यों लगा, और यहां तक ​​कि इस प्रक्रिया को सहन करने के लिए सिस्टम स्पष्ट रूप से कठिन है?

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

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

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



क्या Skype 158 MB मेमोरी लेता है? क्या आप इस बात पर विचार कर रहे हैं कि QIP 35 एमबी है? ठीक है, 35 एमबी शायद बहुत अधिक है, और इसे हल किया जाना चाहिए, लेकिन मेरा नोट उसके बारे में नहीं है। अब हम Skype के बारे में हैं। यह इतने सारे संसाधन क्यों लेता है - क्यूआईपी से लगभग 5 गुना अधिक? संपर्कों की सूची के साथ एक रूप के लिए यह बहुत अधिक है, क्या आप नहीं हैं?

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

, ? 4-8 . 140 , .

हाँ हाँ। बेशक। यदि ऐसा है तो सभी सॉफ्टवेयर डेवलपर्स तर्क देंगे, तो इस तरह से " कोई भी अस्थिरता पर्याप्त नहीं है ।" सवाल यह नहीं है कि मुझे स्काइप मेमोरी के लिए खेद है (और मुझे खेद है)। सवाल यह है कि स्काइप के नए संस्करणों (पुराने वाले की तुलना में) में क्या इतना नया है, कि उन्हें इतनी मेमोरी की आवश्यकता है?

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

इतिहास का हिस्सा

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



जैसा कि आप देख सकते हैं, कहीं न कहीं 2004 में, प्रोसेसर घड़ी की आवृत्ति के मामले में छत पर पहुंच गए। और पिछले 10 वर्षों में, यह आवृत्ति विशेष रूप से बढ़ नहीं रही है। क्या यह इस बात से चलता है कि मूर का कानून पूरा नहीं हुआ है? दरअसल, नहीं, और लेख स्पष्ट रूप से और स्पष्ट रूप से बताता है कि क्यों। बस, हमारे कंप्यूटर का प्रदर्शन अब अन्य कारकों (कैश और मल्टीकोर) के कारण बढ़ रहा है। हालांकि, पकड़ यह है कि सामान्य एकल-थ्रेडेड अनुप्रयोग इन कारकों को गति देने में सक्षम नहीं होंगे। और यहाँ समस्या है। तथ्य यह है कि कई सॉफ्टवेयर निर्माता आज व्यवहार करते हैं जैसे कि यार्ड अभी भी 80 या 90 के दशक का है, और घड़ी के चक्र की संख्या को कम करने के मामले में सॉफ्टवेयर अनुकूलन एक विशेष समस्या पेश नहीं करता है - आप बस थोड़ा इंतजार कर सकते हैं और प्रोसेसर करेंगे काफी तेज।

यह न केवल माइक्रोसॉफ्ट के लिए सच है, बल्कि मैं इसके लिए विशिष्ट उदाहरणों पर ध्यान केंद्रित करूंगा। जोएल स्पोल्स्की ने अपने लेख में उल्लेख किया है कि माइक्रोसॉफ्ट 80 के दशक में एक्सेल और 123 के बीच लड़ाई में लोटस पर हावी होने में कामयाब रहा, इस तथ्य के कारण कि लोटस प्रबंधकों ने एक महत्वपूर्ण गलती की - उन्होंने आवेदन को अनुकूलित करने का प्रयास किया । विशेष रूप से, उन्होंने एप्लिकेशन को सिकोड़ने का प्रयास किया ताकि यह हमेशा 640 KB रैम में फिट होने की गारंटी दे। उन्होंने इसे डेढ़ साल तक मार दिया और इस दौरान रेडमंड ने एक्सेल का उपयोग करके बाजार पर कब्जा कर लिया, क्योंकि उस समय बहुत अधिक मात्रा में रैम वाले कंप्यूटर चालू थे। इस घोल में लोटस की काफी लागत थी।

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

मुद्रास्फीति

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

अंग्रेजी में एक स्थिर मुहावरा है, जो रूसी में लगता है जैसे "कुछ को ठीक करने की कोशिश कर रहा है जो टूट नहीं गया है।" पिछले 10 वर्षों में सॉफ्टवेयर की स्थिति इस मुहावरे की बहुत याद दिलाती है। Skype इसका एक प्रमुख उदाहरण है। मंचों से देखते हुए, यह स्मृति समस्या Skype के पुराने संस्करणों में मौजूद नहीं थी, उदाहरण के लिए, 3.x संस्करणों में। तब से उत्पाद में क्या सुधार हुआ है कि यह रैम के मामले में इतना महंगा हो गया है?

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

Microsoft Office को मत भूलना। मेरी राय में, XP के लिए संस्करण ने सभी को संतुष्ट किया। बेशक, किसी भी उत्पाद की तरह, इसकी कमियां थीं। लेकिन क्या वे इतने महत्वपूर्ण थे कि उन्हें 2007, 2010 आदि संस्करणों को जारी करने की आवश्यकता थी? मैं उनमें समान दस्तावेज बनाता हूं, लेकिन अब मुझे इन प्रणालियों के बूट होने तक अधिक इंतजार करना होगा।

औचित्य में, हम सुनते हैं कि नए संस्करणों में नई विशेषताएं हैं। हां, मैं इससे इनकार नहीं करता, लेकिन क्या यह अजीब नहीं लगता कि इतने पुराने अवसरों को करने के लिए अधिक संसाधनों की आवश्यकता होती है?

प्रतिरूपकता और अनुकूलन

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

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

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

कल्पना कीजिए कि प्रत्येक पुस्तकालय के विकासकर्ता ने अपने पुस्तकालय को 5% धीमा कर दिया, यदि वह अनुकूलन पर अतिरिक्त प्रयास कर सकता था। लाइब्रेरी 1 को अपने काम में लाइब्रेरी 2 का उपयोग करें, और वह लाइब्रेरी 3, और वह लाइब्रेरी 4. इस मामले में, विलंब के संचय के मामले में 15 पुस्तकालयों की एक श्रृंखला का परिणाम 1.05 ^ 15 = 2.07, अर्थात मिलता है। सबसे खराब स्थिति में, एप्लिकेशन किसी भी घटक की तुलना में दो बार धीमी गति से चलेगा।

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

वैकल्पिक उदाहरण

सिद्धांत रूप में, सॉफ्टवेयर उद्योग 70 के दशक के तेल संकट के बाद मोटर वाहन उद्योग के समान है, जब यह स्पष्ट हो गया कि गैसोलीन एक गंभीर रूप से महंगा संसाधन बन रहा था। तब से, कार कंपनियों ने इंजन की खपत को लगभग एक तिहाई कम कर दिया है, अगर मैं गलत नहीं हूँ।

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

तुलना के लिए, ग्लासफिश पर, यदि आपने कई सौ या हजारों वर्गों में से एक को बदल दिया है, तो आपको पूरे मॉड्यूल (युद्ध / कान / जार) को फिर से स्थापित करने की आवश्यकता है। जाने पर फ़ंक्शंस या क्लासेस की हॉट स्वैपिंग होती है, लेकिन एर्लांग के साथ तुलना में इसे बहुत खराब तरीके से लागू किया जाता है।

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