मोबाइल प्लेटफॉर्म पर वेब ऐप्स क्यों धीमा हैं

अनुवादक से

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

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

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

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

लेख सूखी भाषा में लिखा गया है, क्योंकि अध्ययन के तहत विषय को कई बार कई रूपों में चूसा गया है। यदि आप "मोबाइल वेब एप्लिकेशन चूसना" / "नर्क" के बारे में 30 सेकंड की बात पढ़ना चाहते हैं ! नहीं , यह लेख आपके लिए नहीं है ( अनुवादक से: यहां मूल लेख में ऐसी अंग्रेजी-भाषा की चर्चाओं के बहुत सारे लिंक हैं )। दूसरी ओर, जहाँ तक मुझे पता है, वेब पर इस समस्या का पूर्ण, वस्तुनिष्ठ, साक्ष्य-आधारित चर्चा नहीं है। यह एक मूर्खतापूर्ण उपक्रम हो सकता है, लेकिन यह लेख एक समस्या के बारे में आश्वस्त और सूचनात्मक रूप से बोलने का एक प्रयास है, जिसमें से 100% चर्चाएं आमतौर पर एक समग्रता में आती हैं। अपने बचाव में, मैं कह सकता हूं कि मेरा मानना ​​है कि यह समस्या के कारण नहीं है, बल्कि इसके प्रतिभागियों द्वारा चर्चा की गुणवत्ता में सुधार करने की अनिच्छा के कारण है। मुझे विश्वास है कि हम पता लगाएंगे कि क्या ऐसा है।

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

अवलोकन

SunSpider के प्रदर्शन परीक्षणों पर आधारित मेरा पिछला लेख , तर्क देता है कि, इस समय, मोबाइल प्लेटफ़ॉर्म पर वेब एप्लिकेशन धीमा हैं:

"अगर एक 'वेब एप्लिकेशन' का अर्थ 'एक बटन के साथ एक पृष्ठ' है, तो SunSpider जैसे आरामदायक प्रदर्शन परीक्षण करेंगे। लेकिन हल्के फोटो प्रसंस्करण, हल्के टाइपिंग, उपयोगकर्ता-साइड डेटा को संग्रहीत करना और एआरएम आर्किटेक्चर पर चलने वाले वेब एप्लिकेशन में स्क्रीन के बीच एनिमेशन करना केवल एक कारण से होना चाहिए: यदि आपका जीवन नश्वर खतरे में है। "

आपको उस लेख को पढ़ना चाहिए, लेकिन वैसे भी, यहाँ परीक्षा परिणाम हैं:

इस ग्राफ पर आपत्तियों की तीन महत्वपूर्ण श्रेणियां हैं:
1. यह तथ्य कि जेएस मूल कोड की तुलना में धीमा है, यह नया नहीं है: यह CS1 और संकलित, JIT और व्याख्या की गई भाषाओं की चर्चा के बाद से सभी को ज्ञात है। एकमात्र सवाल यह है कि क्या जेएस आपके विशिष्ट कार्य के लिए बहुत धीरे-धीरे काम कर रहा है - और सिंथेटिक परीक्षण इस प्रश्न का उत्तर नहीं देते हैं।
2. हाँ, JS धीमा है और यह रास्ते में हो जाता है, लेकिन जल्दी या बाद में यह इतना तेज़ हो जाएगा कि यह आपके कार्य को खींच लेगा (बिंदु 1 देखें), इसलिए यह JS में निवेश शुरू करने का समय है।
3. मैं पायथन / पीएचपी / रूबी में सर्वर कोड लिखता हूं और आपको पता नहीं है कि आप सभी किस बारे में बात कर रहे हैं। मुझे पता है कि मेरे सर्वर आपके मोबाइल फोन की तुलना में अधिक तेज़ हैं, लेकिन मैं निश्चित रूप से एक्स, 000 उपयोगकर्ताओं की व्याख्या की गई प्रोग्रामिंग भाषा का उपयोग कर रहा हूं, और आप यह पता नहीं लगा सकते हैं कि जेआईटी भाषा में किसी को कैसे संतुष्ट किया जाए?

मेरा लक्ष्य पारलौकिक है - मैं इस लेख में इन तीनों कथनों का खंडन करना चाहता हूँ! हां, जेएस इतना धीमा है कि यह अनुपयोगी हो जाता है; नहीं, यह आने वाले वर्षों में काफी तेज नहीं होगा; नहीं, स्क्रिप्टिंग भाषाओं में सर्वर-साइड प्रोग्रामिंग का आपका अनुभव पर्याप्त रूप से मोबाइल प्लेटफार्मों पर स्थानांतरित नहीं किया जा सकता है।

एक नियम के रूप में, इस तरह के लेखों में "उन्होंने हाथी को नोटिस भी नहीं किया", अर्थात, किसी ने भी यह मापने की कोशिश नहीं की कि जेएस कितना धीमा था या उसने ऐसा करने के लिए एक उपयोगी, उपयुक्त तरीका पेश किया (ठीक है, आप जानते हैं ... धीमी, क्या की तुलना में?)। इस लेख में, मैं एक नहीं, बल्कि JS प्रदर्शन के संबंध में प्रदर्शन समतुल्यता को मापने के लिए तीन तरीके प्रदान करूंगा। इसलिए, मैं न केवल "ब्ला ब्ला ब्ला जेएस धीमा" पर बात करने जा रहा हूं, बल्कि मैं कई कार्यों के संबंध में माप की तुलनाओं को बताऊंगा, जो आप वास्तव में डेवलपर्स के रूप में सामना करते हैं, इसलिए आप अपने लिए यह पता लगा सकते हैं कि आपके विशिष्ट कार्य के लिए पर्याप्त प्रदर्शन है या नहीं।

ठीक है, वास्तव में प्राकृतिक कोड के संबंध में सटीक जावासर्विट निष्पादन कैसे प्राप्त करें?

अच्छा सवाल है। इसका उत्तर देने के लिए, मैंने बेंचमार्क गेम से एक यादृच्छिक बेंचमार्क चुना। फिर मुझे पुराने सी प्रोग्राम मिले जो वही काम करता है (पुराना वाला, क्योंकि नए वाले में सभी प्रकार के x86 ऑप्टिमाइज़ेशन हैं)। फिर मैंने अपने वफादार iPhone 4S पर LLVM के संबंध में नाइट्रो ( अनुवादक से: सफारी जेएस इंजन ) के प्रदर्शन को मापा। सभी कोड GitHub पर उपलब्ध है ।

हाँ, यह सब बहुत यादृच्छिक कोड है। लेकिन वास्तविक जीवन में, कोड कम यादृच्छिक नहीं है। यदि आप एक बेहतर प्रयोग करना चाहते हैं - झंडा आपके हाथों में है। मैंने यह प्रयोग केवल इस कारण से किया कि मुझे अन्य समान (नाइट्रो और एलएलवीएम की तुलना) नहीं मिली।

किसी भी मामले में, इस सिंथेटिक परीक्षण में, एलएलवीएम ( अनुवादक से: देशी कोड ) नाइट्रो की तुलना में लगभग 4.5 गुना तेज है ( अनुवादक से: जावास्क्रिप्ट कोड )।


इसलिए यदि आप सोच रहे हैं - "नाइट्रो जेएस पर चलने की तुलना में यह मेरे कार्य को कितनी तेजी से चलाती है", तो जवाब है: यह लगभग 5 गुना तेजी से काम करता है। यह परिणाम मोटे तौर पर बेंचमार्क गेम के परिणामों से मेल खाता है, जहां x86 / GCC / V8 की तुलना की जाती है। उनका दावा है कि GCC / x86, V8 / x86 की तुलना में औसतन दो से नौ गुना तेज है। इसलिए मुझे जो परिणाम मिला वह दुनिया की तस्वीर से बाहर नहीं है, और यह एआरएम वास्तुकला और x86 दोनों के लिए सच है।

लेकिन सभी के लिए 640K मेमोरी 1/5 पूर्ण नहीं है?

काफी x86 पर। टेबलेट पाने के लिए वास्तव में, ठीक है, संसाधन-गहन कैसे है? ज्यादा नहीं। एक समस्या: एआरएम x86 नहीं है।

GeekBench के अनुसार, नवीनतम मैकबुक प्रो पिछले iPhone की तुलना में तेजी का परिमाण है । ठीक है, ठीक है, गोलियाँ अभी भी पर्याप्त हैं। हमारे लिए उत्पादकता का 10% पर्याप्त है। एक दूसरा! क्या आप इन 10% को अन्य 5 से विभाजित करना भूल गए हैं? इसलिए, नीचे की पंक्ति में, हमारे पास डेस्कटॉप की उत्पादकता का केवल 2% है (मैं इकाइयों को थोड़ा लापरवाह कर रहा हूं, लेकिन हमारे तर्क के लिए, सटीकता पर्याप्त है)।

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


यह ग्राफ़ स्पष्ट रूप से दिखाता है कि iPhone 4S उस समय ब्राउज़रों के साथ प्रतिस्पर्धा नहीं कर सकता जब Google ने दस्तावेज़ सहयोग जोड़ा। खैर, यह है कि यह IE8 से आगे निकल जाता है, बधाई!

आइए एक और गंभीर जेएस एप्लिकेशन पर ध्यान दें: Google Wave। वेव ने IE8 ( Google के अनुसार) में कभी काम नहीं किया क्योंकि यह बहुत धीमा था।


कृपया ध्यान दें कि समर्थित ब्राउज़र 1000 के भीतर थे, और 3800 का उत्पादन करने वाले को बाहर रखा गया था क्योंकि यह धीमा था। IPhone 2400 का उत्पादन करता है। और IE8 की तरह, यह वेव लॉन्च करने के लिए पर्याप्त शक्तिशाली नहीं है।

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

लेकिन क्या मैंने V8 / MODERN-JAVASCRIPT की खोज पूरी की है, जो C पर लागू होने वाले आवेदन की तुलना में है?

"तुलनीय" माना जाता है पर निर्भर करता है। यदि C प्रोग्राम को 10 ms में निष्पादित किया जाता है, तो 50 ms JS प्रोग्राम को "तुलनीय" माना जा सकता है। लेकिन अगर सी-एप्लिकेशन को 10 सेकंड लगते हैं, तो अधिकांश के लिए 50 सेकंड का जेएस आवेदन पहले से ही अतुलनीय है।

हार्डवेयर से बुकिंग

लैग 5 बार, सामान्य रूप से, x86 प्लेटफॉर्म पर डरावना नहीं है, क्योंकि x86, एक शुरुआत के लिए, एआरएम की तुलना में तेजी का परिमाण है। एक स्टॉक है। समाधान सरल है: एआरएम उत्पादकता को 10 गुना बढ़ाने के लिए और - वॉइला - हमें मोबाइल डिवाइस पर डेस्कटॉप प्रदर्शन मिलेगा।

इस तरह से या किसी अन्य की व्यवहार्यता मूर के कानून में आपके विश्वास के इर्द-गिर्द घूमती है, जो 80 जी बैटरी पर चलने वाली चिप को गति देने की कोशिश कर रहा है। हार्डवेयर इंजीनियर नहीं होने के कारण, मैंने एक बड़ी अर्धचालक कंपनी के लिए काम किया और उसके कर्मचारियों ने मुझे बताया कि फिलहाल उत्पादकता एक तकनीकी प्रक्रिया (यह कचरा, जिसे नैनोमीटर में मापा जाता है) का परिणाम है। IPhone 5 की प्रभावशाली प्रदर्शन वृद्धि काफी हद तक विनिर्माण प्रक्रिया में कमी के कारण है - 45 एनएम से 32 एनएम तक - लगभग एक तिहाई। इस कदम को दोहराने के लिए, Apple को विनिर्माण प्रक्रिया को 22 एनएम तक कम करना होगा।

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

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

पूर्व इंटेल इंजीनियर से टिप्पणी:

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

एक रोबोटिक्स इंजीनियर से नोट:

आप बिलकुल सही हैं जब आप कहते हैं कि उत्पादकता में कोई उल्लेखनीय वृद्धि नहीं होगी, और यह कि इंटेल केवल कुछ वर्षों में अधिक कुशल मोबाइल प्रोसेसर प्राप्त करेगा। वास्तव में, मोबाइल प्रोसेसर उस सीमा में भाग गया, जिसमें डेस्कटॉप प्रोसेसर चला था जब वे ~ 3 Ghz की आवृत्ति तक पहुँच गए थे: आवृत्ति में और वृद्धि से बिजली की खपत में तीव्र वृद्धि होती है और यह नियम निम्न प्रक्रियाओं पर भी लागू होगा, हालाँकि वे IPC को थोड़ा बढ़ा देंगे; 10-20%)। इस सीमा के विपरीत, डेस्कटॉप प्रोसेसर मल्टी-कोर बन गए हैं, लेकिन मोबाइल सिस्टम-ऑन-ए-चिप पहले से ही मल्टी-कोर हैं, इसलिए प्रदर्शन में कोई आसान वृद्धि नहीं होगी।

इसलिए, शायद मूर का कानून पूरा हो गया है, लेकिन इस शर्त पर कि पूरा मोबाइल पारिस्थितिकी तंत्र x86 पर जाता है। यह बिल्कुल असंभव नहीं है - यह पहले किया गया था । लेकिन उस समय, बिक्री प्रति वर्ष लगभग एक मिलियन डिवाइस थी, और अब एक तिमाही में 62 मिलियन बेची जाती है। यह वर्चुअलाइजेशन का उपयोग करके किया गया था, जिसने 60% प्रदर्शन पर पुरानी वास्तुकला का अनुकरण किया, जबकि अनुकूलित (O3) एआरएम कोड के लिए आधुनिक काल्पनिक वर्चुअलाइजेशन 27% के करीब हैं।

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

मुझे डर है कि मेरा हार्डवेयर ज्ञान यहाँ समाप्त होगा। यदि आप विश्वास करना चाहते हैं कि एआरएम 5 वर्षों में x86 के साथ पकड़ लेगा, तो पहला कदम एआरएम या इंटेल पर काम करने वाले और आपके साथ सहमत होने वाले व्यक्ति को ढूंढना है। मैंने कई समान इंजीनियरों के साथ परामर्श किया और उन सभी ने इस दावे को खारिज कर दिया। यह इस प्रकार है कि ऐसा न होने की सबसे अधिक संभावना है।

सॉफ़्टवेयर से बुकिंग

कई सक्षम प्रोग्रामर एक ही गलती करते हैं। वे निम्नानुसार दर्शाते हैं: जावास्क्रिप्ट पहले से ही बहुत तेज था! और यह तेजी से और तेज हो जाएगा!

पैकेज सही है। जावास्क्रिप्ट ने गंभीरता से त्वरित किया है। लेकिन हम वर्तमान में जावास्क्रिप्ट प्रदर्शन के चरम पर हैं। आगे त्वरण शायद ही संभव है।

कारण? शुरू करने के लिए, ध्यान दें कि इसके इतिहास में अधिकांश जेएस सुधार वास्तव में हार्डवेयर से संबंधित हैं । जेफ एटवुड लिखते हैं :

मैंने पाया कि 1996 से 2006 तक जावास्क्रिप्ट का प्रदर्शन 100 गुना बढ़ा। वेब 2.0 का निर्माण "कंकाल के कंकाल पर" मुख्य रूप से मूर के प्रदर्शन में वृद्धि के कारण संभव हुआ।

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

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

तुम सिर्फ मुझे गलत मत करो - उत्पादकता में 9 गुना वृद्धि - मजाक नहीं; आखिरकार, एआरएम और x86 के बीच लगभग समान बिजली का अंतर है। हालांकि, क्रोम 8 और क्रोम 26 के बीच प्रदर्शन अंतर एक कोमल वक्र है, क्योंकि 2008 के बाद से यहां कुछ भी क्रांतिकारी नहीं हुआ है। अन्य ब्राउज़र निर्माताओं ने खुद को ऊपर खींच लिया - कहीं थोड़ा धीमा, कहीं थोड़ा तेज, लेकिन तब से कोई भी कोड की गति में गंभीरता से सुधार नहीं कर सका।

क्या JAVASCRIPT की उत्पादकता बढ़ रही है?

यहाँ मेरे मैक पर क्रोम 8 है (जल्द से जल्द अभी भी काम कर रहा है, दिसंबर 2010)। और यहाँ क्रोम 26 है ।

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

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

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

लेकिन SAFARI पूरी तरह से बेहतर काम करता है

लेकिन अगर सब कुछ जैसा कि आप कहते हैं, हम लगातार जेएस प्रदर्शन में उल्लेखनीय वृद्धि के बारे में क्यों सुनते हैं? हर हफ्ते, कोई अन्य प्रदर्शन परीक्षण में किसी अन्य त्वरण के बारे में बात करता है। यहाँ Apple ने JBench परीक्षण पर गति में आश्चर्यजनक 3.8 गुना वृद्धि हासिल करने का दावा किया है:

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

यह आरेख स्पष्ट रूप से दिखाता है कि, SunSpider परीक्षण के अनुसार, FireFox का प्रदर्शन संस्करण 1.5 से संस्करण 3.6 में 13 गुना बढ़ गया है। हालांकि, अगर आप अमेजन परीक्षण में प्रदर्शन को देखते हैं, तो यहां हम 3 गुना की मामूली वृद्धि देखते हैं। क्या उत्सुक है, पिछले दो वर्षों में, अमेज़ॅन परीक्षण में प्रदर्शन वृद्धि व्यावहारिक रूप से नहीं देखी गई है। मेरा मानना ​​है कि सनस्पाइडर परीक्षण में काम करने वाले कई अनुकूलन अमेजन परीक्षण में भूमिका नहीं निभाते हैं।

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

उच्च प्रदर्शन के लिए तैयार नहीं है

( अनुवादक से: बाईं पुस्तक को "जावास्क्रिप्ट: अच्छा पक्ष" कहा जाता है, दाईं ओर "जावास्क्रिप्ट: पूर्ण संदर्भ" है )। हर्ब सटर

को उद्धृत करने के लिए , आधुनिक C ++ की दुनिया में सबसे बड़ी:

— « (JIT ) managed » . , C# Java — JIT, NGEN- . , , . -, JIT . : managed , । विशेष रूप से, प्रबंधित प्लेटफार्मों के रचनाकारों ने कुछ सुविधाओं पर संसाधनों को खर्च करने का फैसला किया, भले ही उनका उपयोग एप्लिकेशन द्वारा न किया गया हो; मुख्य विशेषताएं हैं: हमेशा चलने वाला कचरा संग्रह, वर्चुअल मशीन निष्पादन प्रणाली और मेटाडेटा। लेकिन इतना ही नहीं, अन्य उदाहरण भी हैं: प्रबंधित भाषाओं में, फ़ंक्शन कॉल डिफ़ॉल्ट रूप से आभासी हैं, जबकि C ++ में, डिफ़ॉल्ट रूप से कॉल इनलाइन हैं ( अनुवादक से: अर्थात, फ़ंक्शन बॉडी को कॉल / रिट के बजाय सीधे कोड में संकलित किया जाता है ) और एक चम्मच। इनलाइन रोकथाम लागत अनुकूलन के अनुकूलन के बैरल।

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

managed (.NET, Java JavaScript). managed .

या रूबी जेआईटी ऑप्टिमाइज़र प्रोजेक्ट का समर्थन करने वाले एलेक्स गेन्नोर से पूछें और पायथन जेआईटी ऑप्टिमाइज़र प्रोजेक्ट में भी भाग लें:

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

Google को लगता है कि जावास्क्रिप्ट ने प्रदर्शन सीमा की दीवार को मारा है:

परिष्कृत वेब अनुप्रयोग - जो Google माहिर हैं - प्लेटफ़ॉर्म दोषों में चलते हैं और एक ऐसी भाषा पर आधारित होते हैं जिसे अनुकूलित नहीं किया जा सकता है और इसमें अंतर्निहित प्रदर्शन समस्याएं हैं।

अंत में, अपने आप को सुनो। मेरे एक पाठक ने मुझे ब्रेंडन ईच की इस टिप्पणी की ओर इशारा किया । खैर, आप जानते हैं, यह वही आदमी है जिसने जावास्क्रिप्ट का आविष्कार किया था।

माइक एक बात का उल्लेख करना भूल गया: भाषा को सरल बनाएं । Lua JS की तुलना में बहुत सरल है। इसका मतलब यह है कि आप एक सरल व्याख्याकार बना सकते हैं जो JIT कोड के प्रदर्शन (जो JS के लिए असंभव है) के साथ तुलना करने के लिए पर्याप्त तेजी से काम करता है

और थोड़ा कम:

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

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

लेकिन एक समस्या और भी महत्वपूर्ण है।

सभी ट्रूथ जीसी के बारे में

तथ्य यह है कि कंप्यूटिंग शक्ति से जुड़ी प्रदर्शन समस्या - और इस विषय पर सभी परीक्षण, और सभी इंजीनियरिंग समाधान - सिक्के का केवल एक पक्ष है। दूसरी स्मृति है। और, यह पता चल सकता है कि स्मृति समस्या इतनी महान है कि कम्प्यूटेशनल प्रदर्शन का प्रश्न हिमशैल के टिप जैसा है। वास्तव में, कम्प्यूटेशनल समस्याओं की चर्चा केवल वास्तविक समस्याओं से ध्यान हटाने के लिए होती है। निम्नलिखित लिखा है कि गंभीरता से मोबाइल अनुप्रयोगों के विकास के अपने विचार बदल सकते हैं।
2012 में, Apple ने एक मजाकिया और अप्रत्याशित कदम उठाया (आपके लिए अप्रत्याशित, जब तक आप जॉन ग्रुबर नहीं थे और यह भविष्यवाणी की थी )। उन्होंने OSX से कचरा कलेक्टर को हटा दिया। चुटकुलों के अलावा, प्रोग्रामर के गाइड को पढ़ें। ऊपरी दाएं कोने में बोल्ड में यह कहता है "उपयोग के लिए अनुशंसित नहीं है।" यदि आप रूबी, या पायथन, या जावास्क्रिप्ट, या जावा, या सी #, और 1990 के बाद बनाई गई किसी भी भाषा से आए हैं, तो यह खबर भारी होनी चाहिए। यह प्रभावित नहीं करेगा, क्योंकि आप ओबीसी पर मैक के तहत लिखने की संभावना नहीं है। लेकिन, फिर भी, यह अजीब लगता है । अंत में, कचरा संग्रहकर्ता लंबे समय से हमारे साथ हैं और समय-परीक्षण किया जाता है । वे किस बात को अप्रचलित घोषित करते हैं ? यहाँ Apple कहते हैं:

हमें यकीन है कि एआरसी मेमोरी प्रबंधन के लिए सही दृष्टिकोण है जिसे हमने OSX में कचरा कलेक्टर को छोड़ने का फैसला किया (- सत्र 101, प्लेटफार्म किकऑफ, 2012, ~ 01: 13: 50)

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

एआरसी एक जीसी नहीं है

यह सुनिश्चित करने के लिए कि ARC एक कचरा संग्रहकर्ता है, मैं इस स्लाइड के साथ Apple के चेहरे में एम्बेड करूंगा:

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

WASTE गैदर इतना अच्छा नहीं है, आपको कितना अनुभव होता है

जब उन्होंने इसे दबाया तो Apple ने ARC बनाम GC (कचरा संग्रहकर्ता) के बारे में क्या कहा:

उन लोगों के बीच सबसे महत्वपूर्ण इच्छा जो हम आपके लिए कर सकते हैं, कचरा कलेक्टर को आईओएस पर वापस करना है। और ठीक यही हम नहीं करेंगे। दुर्भाग्य से, कचरा कलेक्टर गंभीरता से प्रदर्शन को कम करता है। आपका आवेदन कचरा जमा कर सकता है और अनुमत मेमोरी सीमा को पार कर सकता है। और कचरा संग्रह समय पर अप्रत्याशित बिंदुओं पर शुरू होता है, जो उपयोगकर्ता इंटरफ़ेस में सीपीयू संसाधन और हिचकी के भक्षण की ओर जाता है। यही कारण है कि जीसी हमारे मोबाइल प्लेटफार्मों पर हमारे लिए उपयुक्त नहीं है। जीएस के विपरीत, अनुरक्षण / रिलीज के माध्यम से प्रत्यक्ष स्मृति प्रबंधन को समझना मुश्किल है और, स्पष्ट रूप से, अधिक बवासीर का उपयोग करने के लिए। लेकिन प्रदर्शन उच्च और अधिक अनुमानित है, और इसलिए प्रत्यक्ष नियंत्रण को हमारी स्मृति प्रबंधन रणनीति के लिए आधार के रूप में चुना गया था। क्योंकि, वास्तविक दुनिया में, हमारे उपयोगकर्ताओं (~ सत्र 300, डेवलपर टूल किकऑफ़, 2011, 00:47:49) के बीच उच्च प्रदर्शन और एक चिकनी इंटरफ़ेस उच्च मूल्य के हैं।

लेकिन क्या यह पागल है ?! आरंभ करने के लिए:
1. यह डेस्कटॉप पर आपके सभी करियर के अनुभवों से पूरी तरह विपरीत है;
2. विंडोज मोबाइल, एंड्रॉइड, मोनोआच और कई अन्य जीसी से काफी संतुष्ट लगते हैं।
आइए उन पर नजर डालते हैं।

मोबाइल प्लेटफॉर्म पर जीसी डेस्कटॉप पर कचरा कलेक्टर के समान नहीं है

मुझे पता है कि तुम क्या सोचते हो। आप पायथन में एन वर्षों से प्रोग्रामिंग कर रहे हैं। अब वर्ष 2013 है। कचरा संग्रहण की समस्या पूरी तरह से और पूरी तरह से हल हो गई है।
यहां वह दस्तावेज़ है जिसे आप ढूंढ रहे हैं। ऐसा लगता है कि समस्या पूरी तरह से हल नहीं हुई है :

यदि आपके पास इस लेख में एक चीज़ बची है, तो इसे इस स्लाइड पर जाने दें । Y अक्ष कचरा संग्रहण पर खर्च किया जाने वाला समय है। एक्स अक्ष "सापेक्ष मेमोरी खपत" है। किससे संबंधित? न्यूनतम आवश्यक स्मृति आकार के लिए ।
यहाँ यह स्लाइड हमें बताना चाहता है: “जब तक आपके पास वास्तव में ज़रूरत से 6 गुना अधिक मेमोरी है, आप चॉकलेट में हैं। लेकिन अगर आप आवश्यक स्मृति के 4 आकारों से नीचे आते हैं, तो आपके लिए शोक है । " इसके लिए मेरा शब्द लेना आवश्यक नहीं है:

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

चलो प्रत्यक्ष (स्पष्ट) स्मृति प्रबंधन के साथ तुलना करें:

ये ग्राफ़ दिखाते हैं कि यदि मेमोरी की एक उचित मात्रा एप्लिकेशन को उपलब्ध है (लेकिन पूरे एप्लिकेशन को फिट करने के लिए पर्याप्त नहीं है), दोनों प्रत्यक्ष मेमोरी मैनेजर सभी कचरा संग्रहकर्ताओं को महत्वपूर्ण रूप से बेहतर बनाते हैं। उदाहरण के लिए, 63 MB उपलब्ध मेमोरी और ली एलोकेटर के साथ pseudoJBB 25 सेकंड में कार्य पूरा करता है। जेनएमएस मेमोरी की समान मात्रा 10 गुना लंबी (255 सेकंड) लेती है। किट में शामिल सभी परीक्षणों में समान व्यवहार देखा जाता है। सबसे विशिष्ट परीक्षण 213 जावाक है: एक ली एलोकेटर के साथ 36 एमबी मेमोरी के लिए, कुल रनटाइम 14 सेकंड है, जबकि जेनएमएस पर टेस्ट रन का समय 211 सेकंड है, जो 15 गुना लंबा है।

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

कैसे बहुत याद आईओएस पर लागू है?

यह सुनिश्चित करने के लिए कहना मुश्किल है। उपकरणों पर भौतिक स्मृति का आकार iPhone 5 पर iPhone 4 पर 512 MB से भिन्न होता है। लेकिन इस मेमोरी का अधिकांश उपयोग सिस्टम द्वारा और मल्टीटास्किंग के लिए भी किया जाता है। जाँच करने का एकमात्र तरीका वास्तविक परिस्थितियों में चलना है। Jan Ilavsky ने इस उद्देश्य के लिए एक एप्लिकेशन बनाया , लेकिन किसी ने भी अब तक परिणामों को प्रकाशित नहीं किया है। आज तक।
स्मृति को "सामान्य" स्थितियों में मापना महत्वपूर्ण है, क्योंकि यदि आप लोड करने के तुरंत बाद ऐसा करते हैं, तो परिणाम बेहतर होंगे, क्योंकि सफारी और इस तरह खोले गए पृष्ठों के लिए कोई खर्च नहीं है। इसलिए मैंने शाब्दिक रूप से अपने उपकरणों को अपार्टमेंट के चारों ओर बिखेर दिया और उनके लिए परीक्षण चलाए।


विवरण देखने के लिए, तस्वीर पर क्लिक करें, लेकिन, iPhone 4S पर, तथ्य की बात के रूप में, एप्लिकेशन मेमोरी की कमी के बारे में चेतावनी प्राप्त करना शुरू कर देता है, लगभग 40 एमबी आवंटित करता है, और 213 एमबी (लगभग) के लिए समाप्त हो जाता है। IPad 3 पर, एक 400 एमबी चेतावनी और 550 एमबी समाप्ति। बेशक, ये मेरे परिणाम हैं - यदि उपयोगकर्ता पृष्ठभूमि संगीत सुनता है, तो स्मृति बहुत कम हो सकती है, लेकिन यह कम से कम किसी तरह की दिशानिर्देश है एक शुरुआत के लिए। यह बहुत लगता है (213 एमबी सभी के लिए पर्याप्त होना चाहिए, ठीक है?), लेकिन व्यावहारिक दृष्टिकोण से पर्याप्त नहीं है। उदाहरण के लिए, iPhone 4S 3264 × 2448 पिक्सेल की तस्वीरें लेता है। यह प्रति छवि लगभग 30 एमबी डेटा है। इसका मतलब यह है कि स्मृति में केवल दो छवियां हैं और स्मृति में 7 छवियां रखने वाले एप्लिकेशन को समाप्त करने की चेतावनी प्राप्त होती है। आह, आप एल्बम में फ़ोटो के माध्यम से एक चक्र लिखना चाहते थे? आवेदन बंद हो जाएगा!
यह जोर देना महत्वपूर्ण है कि व्यवहार में अक्सर एक ही तस्वीर को स्मृति में कई स्थानों पर संग्रहीत किया जाता है। उदाहरण के लिए, यदि आप कैमरे से चित्र लेते हैं, तो 1) एक कैमरा स्क्रीन जो यह देखती है कि स्मृति 2 में क्या संग्रहीत है) एक तस्वीर जिसे कैमरे ने 3 लिया) एक बफर जिसमें आप डिस्क को बचाने के लिए JPEG में छवि को संपीड़ित करते हैं) स्नैपशॉट का वह संस्करण जिसे आप अगली स्क्रीन पर दिखाना चाहते हैं 5) स्नैपशॉट का संस्करण जिसे आप किसी सर्वर पर अपलोड करते हैं।
कुछ बिंदु पर, आप समझेंगे कि थंबनेल प्रदर्शित करने के लिए 30 एमबी छवि बफर का उपयोग करना एक अच्छा विचार नहीं है और 6 जोड़ें) आवेदन 7 में थंबनेल के लिए अगली स्क्रीन के लिए एक बफर) एक बफर जिसमें पृष्ठभूमि में थंबनेल बनाया गया है (तब से) यह मुख्य धागे में असंभव है - बहुत धीमा)। और फिर आपको अचानक पता चलता है कि इसके लिए वास्तव में 5 विभिन्न आकारों के थंबनेल की आवश्यकता होती है और धीरे-धीरे पागल होने लगते हैं। एक शब्द में, यहां तक ​​कि एक तस्वीर के साथ काम करते समय , उपलब्ध स्मृति सीमा को पार करना आसान है। आप मुझ पर विश्वास नहीं कर सकते हैं:

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

हां, आप उन पर विश्वास भी नहीं कर सकते। वास्तव में, आपके एप्लिकेशन द्वारा आवंटित की जाने वाली मेमोरी का आकार हिमशैल का टिप है। गंभीरता से, यहां एक स्लाइड है जो हिमखंड को ही दिखाती है (सत्र 242, आईओएस ऐप प्रदर्शन - मेमोरी, 2012):

(स्लाइड अनुवाद: केवल ओबीजेसीटीएस नहीं
* हिप मेमोरी
- * + [[NSObject] आवंटित] / मॉलोक
- * फ्रेमवर्क द्वारा आवंटित ऑब्जेक्ट / बफ़र्स
* अन्य मेमोरी
- * कोड और वैश्विक चर (___TEXT, ___DATA)
- * धारा ढेर
- * छवि डेटा
- * कैलेबर बफ़र्स
- * डेटाबेस कैश
* अपने आवेदन के बाहर स्मृति
)
और यह मोमबत्ती दोनों सिरों से जलती है। यदि डेस्कटॉप के विपरीत, आपके पास केवल 213 एमबी है, तो फ़ोटो के साथ काम करना अधिक कठिन है। और एक ही समय में, फोटो अनुप्रयोगों की मांग बहुत अधिक है, क्योंकि आपके डेस्कटॉप में एक शांत कैमरा नहीं है और यह आपकी जेब में फिट नहीं है ।
एक और उदाहरण लीजिए। IPad 3 के लिए, डिस्प्ले रिज़ॉल्यूशन आपके मॉनिटर के रिज़ॉल्यूशन से अधिक होने की संभावना है (सिनेमैटोग्राफी के संदर्भ में, यह स्क्रीन 2K और 4K के बीच है)। छवि के प्रत्येक फ्रेम में 12 एमबी लगती है। यदि आप मेमोरी सीमा का उल्लंघन नहीं करना चाहते हैं, तो आप एक ही समय में मेमोरी में लगभग 45 फ्रेम के असम्पीडित वीडियो या एनीमेशन को स्टोर कर सकते हैं, जो कि 30 एफपीएस पर 1.5 सेकंड या सिस्टम 60 एफपीएस पर .75 सेकंड का समय लेगा। गलती से फुल-स्क्रीन एनीमेशन का एक दूसरा हिस्सा? आवेदन बंद हो जाएगा। और यहां आप यह भी ध्यान दे सकते हैं कि AirPlay में देरी 2 सेकंड है , इसलिए किसी भी मीडिया एप्लिकेशन के लिए आपको मेमोरी से बाहर चलने की गारंटी दी जाती है ।
और यहाँ फिर से वही समस्या छवि की कई प्रतियों की है। उदाहरण के लिए, Apple का दावा है कि "CALayer प्रत्येक UIView के साथ जुड़ा हुआ है और परत चित्र मेमोरी में बने रहते हैं, जबकि CALayer ऑब्जेक्ट्स के पदानुक्रम में है।" इसका मतलब है कि आपकी प्रस्तुति पदानुक्रम के मध्यवर्ती प्रतिनिधित्व के साथ स्मृति में कई छवियां हो सकती हैं।
लेकिन अभी भी आयतों और परत बफ़र्स की कतरन हैं। यह सीपीयू बचत के संदर्भ में एक शानदार वास्तुकला है, लेकिन इसका प्रदर्शन यथासंभव स्मृति को आवंटित करके प्राप्त किया जाता है। iOS को मेमोरी सेविंग के लिहाज से नहीं, बल्कि हाई परफॉर्मेंस के लिहाज से डिजाइन किया गया था। जो कचरा संग्रह के साथ अच्छी तरह से नहीं जाता है।
और फिर से मोमबत्ती दो छोरों से जलती है। हमारे पास फुल-स्क्रीन एनीमेशन के लिए न केवल बहुत सीमित वातावरण है। लेकिन उच्च-गुणवत्ता वाले वीडियो और एनीमेशन की भारी मांग भी है, क्योंकि यह एक भयानक, अविस्मरणीय वातावरण है वास्तव में एकमात्र फॉर्म फैक्टर है जिसमें आप एक उच्च-गुणवत्ता वाली फिल्म डिस्प्ले खरीद सकते हैं। यदि आप डेस्कटॉप पर इस रिज़ॉल्यूशन के लिए प्रोग्राम बनाना चाहते हैं, तो पहले अपने उपयोगकर्ताओं को केवल एक मॉनिटर पर $ 700 खर्च करने के लिए मनाएं। या वे $ 500 के लिए एक iPad खरीद सकते हैं, और इसमें पहले से ही एक कंप्यूटर है।

याद रखने की योग्यता क्या होगी?

कुछ चतुर लोग मुझे कहते हैं - “ठीक है, आपने हमें आश्वस्त किया कि हमें एक तेज मोबाइल सीपीयू नहीं मिलेगा। लेकिन स्मृति की मात्रा बढ़ेगी, है ना? यह डेस्कटॉप पर बढ़ता गया। ”
इस सिद्धांत के साथ समस्या यह है कि एआरएम में मेमोरी प्रोसेसर पर ही स्थित है । इस सर्किट को पैकेज ऑन (PoP) (अनुवादक से चिप पर चिप) कहा जाता है । इसलिए मेमोरी की मात्रा बढ़ाने की कठिनाइयां वास्तव में सीपीयू को ओवरक्लॉक करने की कठिनाइयों के समान हैं, क्योंकि वे प्रति चिप अधिक ट्रांजिस्टर को समायोजित करने के तरीके के बारे में बताते हैं। मेमोरी ट्रांजिस्टर को पकड़ना थोड़ा आसान है, वे आकार में समान हैं, लेकिन फिर भी मुश्किल हैं।
यदि आप iFixit वेबसाइट पर A6 छवि को देखते हैं, तो आप देखेंगे कि चिप की सतह पर लगभग 100% क्षेत्र मेमोरी द्वारा कब्जा कर लिया गया है। इसका मतलब है कि मेमोरी बढ़ाने के लिए, विनिर्माण प्रक्रिया को कम करना या चिप को बढ़ाना आवश्यक है । और अगर प्रक्रिया प्रौद्योगिकी के सापेक्ष मापा जाता है, तो मेमोरी में वृद्धि हमेशा चिप के आकार में वृद्धि के साथ जुड़ी होती है:

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

PoP के लिए के रूप में। यह वास्तुकला बहुत अच्छी तरह से थ्रूपुट को बेहतर बनाता है और रूटिंग को सरल बनाता है। लेकिन मैं एआरएम से नहीं निपटता और सब कुछ नहीं जानता।

रोबोटिक्स इंजीनियर:

जब पीओपी दुर्लभ हो जाता है, तो "3 डी" मेमोरी "सभी के लिए पर्याप्त मेमोरी" देने में सक्षम होगी: स्टैक्ड मेमोरी चिप्स में 1 जीबी मेमोरी की 10 से अधिक परतों को एक ही वॉल्यूम में रखने की क्षमता है। : , , .
, . - CPU . , CPU . CPU - . CPU: , CPU . .

लेकिन यह कैसे मोनो / एंड्रॉइड / विंडोबाइल्स मोबाइल SUCCESSFULLY नियंत्रण है?

इस प्रश्न के दो उत्तर हैं। ग्राफ से पहला अनुसरण करता है ( अनुवादक से: कचरा लेने वाले द्वारा मेमोरी की खपत ): यदि आपके पास जरूरत से 6 गुना अधिक मेमोरी है, तो कचरा संग्रह तेज है। यदि, उदाहरण के लिए, आप एक पाठ संपादक की प्रोग्रामिंग कर रहे हैं, तो आप आसानी से 35 एमबी की सीमा को पूरा कर सकते हैं, जो कि मेमोरी सीमा का 1/6 है, जिस पर iPhone 4S पर एप्लिकेशन समाप्त हो गया है। तो आप मोनो ले सकते हैं, एक संपादक लिख सकते हैं, सुनिश्चित करें कि यह तेजी से काम करता है और पाता है कि कचरा संग्रह काफी स्मार्ट है। और आप सही होंगे।
हां, लेकिन ज़ामरीन पर, एक उड़ान सिम्युलेटर शामिल है । यह पता चला है कि कचरा संग्रह भी बड़े मोबाइल अनुप्रयोगों के लिए ठीक काम करता है? या नहीं ?

इस गेम को विकसित करते समय आपको किन समस्याओं का सामना करना पड़ा? “प्रदर्शन एक प्रमुख मुद्दा रहा है और सभी प्लेटफार्मों पर ऐसा होना जारी है। पहला विंडोज फोन काफी धीमा था और हमें एक स्वीकार्य एफपीएस प्राप्त करने के लिए अनुकूलन करने में बहुत समय बिताना पड़ा। इन अनुकूलन ने सिमुलेशन कोड और 3 डी इंजन दोनों को प्रभावित किया है। "संकीर्ण गर्दन कचरा संग्रह और GPU की कमजोरी है।"

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

कृपया ध्यान दें - मेरे गैलेक्सी नेक्सस पर एप्लिकेशन चलते हैं - यह बताने के लिए कि कौन सी भाषा धीरे-धीरे घूमती नहीं है। रेंडरिंग पर खर्च किए गए समय को देखें। डेस्कटॉप पर, ये चित्र सौ एमएस के एक जोड़े में बनाए गए थे, जबकि मोबाइल डिवाइस पर इसे परिमाण के दो ऑर्डर अधिक समय लगे । "नरक" ( अनुवादक से: जटिल प्रतिपादन वाला ग्रह ) पर 6 सेकंड से अधिक ? पागलपन! .. इस समय के दौरान, कचरा कलेक्टर 10-15 बार काम करेगा।

अधिक :

real-time , . , Java , . , 100-200 . , ( — CPU). 1.6, , , , ( ) . , , .

या हम स्टैक ओवरफ्लो पढ़ सकते हैं :

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

यहाँ सबसे महत्वपूर्ण जवाब है, पक्ष में 27 वोट:

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

फेसबुक से जॉन पेरलो को सुनो :

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

Microsoft MVP पढ़ें :

33.33 ( : ), 30 FPS… , . , . « », — , ( , ). ( ) , , .

कचरा इकट्ठा करने वाले को हरा देने का सबसे अच्छा तरीका यह है कि वह बिल्कुल न खेले । यह कथन (कमजोर रूप में) आधिकारिक Android प्रलेखन में पाया गया है :

. , , , . , , , . , 2.3, , . , … , , . , , .

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

, WP7 CPU . Silverlight, 100 . . ( ) , (mark) (sweep). , , « » . XNA SL , ( ) /.

अभी भी यकीन नहीं हुआ? Chrome के पास एक परीक्षण है जो कचरा संग्रहण प्रदर्शन को मापता है। आइए देखें कि वह कैसे प्रबंधित करता है ...

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

लिस्टेन, उद्धरण यह है कि मैं उन सभी को पढ़ सकता हूं। लेट अलाइड कंसॉल्यूशन।

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

क्या कचरा संग्रहण करने के लिए क्रोम इंजन प्राप्त करने का कोई तरीका है? आम तौर पर बोलना - नहीं, और यह उद्देश्य पर किया जाता है।

ECMA विनिर्देश में "आवंटन" शब्द शामिल नहीं है, "मेमोरी" का एकमात्र संदर्भ बताता है कि यह पूरी तरह से "पर्यावरण" (मेजबान-परिभाषित) पर निर्भर है।
ECMA संस्करण 6 विकी में कई ड्राफ्ट पृष्ठ हैं , जो निम्नलिखित को उबालते हैं (मैं मजाक नहीं कर रहा हूं):

कचरा संग्रहकर्ता मेमोरी को इकट्ठा नहीं करता है, जिसकी सामग्री को कार्यक्रम के सही निष्पादन को जारी रखने के लिए आवश्यक हो सकता है ... रूट से दुर्गम होने वाले सभी ऑब्जेक्ट्स (साफ) अप्राप्य हैं यदि एप्लिकेशन को सही संचालन जारी रखने के लिए पर्याप्त मेमोरी नहीं है।

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

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

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

और अगर अचानक DAST?

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

निष्कर्ष: कई डेवलपर्स को स्मृति समस्याओं का सामना करना पड़ा है जो आरएम -3 ( एक अनुवादक से: रूबीमोशन बग , जो डेवलपर्स ने 11 जुलाई 2013 को तय किया था ) या रूबीमोशन में कुछ अन्य अनडेटेड मेमोरी आवंटन समस्याओं का परिणाम है।

बेन शेल्डन नोट :

तुम्हारे साथ ही नहीं। मैं स्वयं मेमोरी क्रैश (जैसे SIGSEGV और SIGBUS) में भाग गया, जो 10-20% उपयोगकर्ताओं में होता है।

कुछ संदेह हैं कि क्या समस्या को ट्रैक किया जा सकता है:

मैंने आखिरी बैठक में RM-3 प्रश्न उठाया और लॉरेंट और वाटसन दोनों ने उत्तर दिया। वाटसन ने कहा कि आरएम -3 ठीक करने के लिए सबसे कठिन बग है; लॉरेंट ने कहा कि उसने कई तरीकों की कोशिश की, लेकिन किसी ने मदद नहीं की। दोनों ही शक्तिशाली डेवलपर हैं जिन पर आप भरोसा कर सकते हैं।

यह भी संदेह है कि क्या यह बिल्कुल तय है:

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

RubyMotion की एक और समस्या है - मेमोरी लीक । और अन्य समस्याएं हो सकती हैं। कोई भी गारंटी नहीं दे सकता है कि एक रिसाव 2 या 200 कारणों से होता है। हम सभी जानते हैं कि उपयोगकर्ता लीक की रिपोर्ट करते हैं। बहुत बार।
इसका क्या मतलब है: दुनिया के कुछ सबसे अच्छे डेवलपर्स ने रूबी को विशेष रूप से मोबाइल उपकरणों पर उपयोग करने के लिए फोर्क किया और इसने एक प्रणाली को चालू कर दिया जो स्मृति को क्रैश और खो देता है, जो मेमोरी त्रुटियों का मुख्य सेट है। अब तक, वे इसे ठीक नहीं कर पाए हैं, हालांकि वे स्पष्ट रूप से अपना सर्वश्रेष्ठ प्रयास कर रहे हैं। और वे दावा करते हैं कि "उन्होंने इसे कई बार ठीक करने की कोशिश की, लेकिन उन्हें एक अच्छा समाधान नहीं मिला (जो प्रदर्शन को बनाए रखता है)।"
मैं यह दावा नहीं करता कि मेमोरी के साथ काम करने पर जावास्क्रिप्ट को स्वीकार्य प्रदर्शन प्राप्त करना असंभव है। मैं सिर्फ इतना कहना चाहता हूं कि ऐसा करना बहुत मुश्किल है।
अनुपूरक। जंग परियोजना के सदस्य:

Rust, (zero-overhead memory safety). GC- "@-" ( "@ T" T) , , . , , ( ). , , , JavaScript.

, ASM.JS?

ams.js दिलचस्प है कि यह एक जावास्क्रिप्ट मॉडल प्रदान करता है, लेकिन एक कचरा कलेक्टर के बिना। सैद्धांतिक रूप से, "सही" ब्राउज़र में और सही API के साथ, यह जल सकता है। सवाल यह है कि क्या हमें "सही ब्राउज़र" मिलता है।
मोज़िला, प्रौद्योगिकी के लेखक होने के नाते, निश्चित रूप से, आसानी से सहमत हैं और कार्यान्वयन इस वर्ष के अंत में दिखाई देगा। क्रोमियम की प्रतिक्रिया अधिक मिश्रित होती है। जाहिर है, यह Google के स्वयं के विकास के साथ प्रतिस्पर्धा करता है: डार्ट और PNaCl। इस संबंध में एक बग भी है , लेकिन वी 8 हैकर्स में से एक उसे पसंद नहीं करता है । Apple के लिए, WebKit के लोग चुप हैं । आईई? कोई उम्मीद नहीं है।
किसी भी मामले में, यह बहुत स्पष्ट नहीं है कि यह केवल सही फिक्स्ड जावास्क्रिप्ट क्यों सभी अनुरोधों को पूरा करेगा। यहां तक ​​कि अगर वह जीतता है, तो यह जावास्क्रिप्ट होने की संभावना नहीं है। अंत में, यह कचरा कलेक्टर की अस्वीकृति द्वारा उत्पन्न होता है। तो यह C / C ++ या मैनुअल मेमोरी मैनेजमेंट वाली दूसरी भाषा के समान हो सकता है। लेकिन यह निश्चित रूप से उस गतिशील भाषा नहीं होगी जिसे हम जानते हैं और प्यार करते हैं।

कम क्या है?

"X धीमा है" और "X धीमा नहीं है" कथनों में से एक समस्या यह है कि कोई भी संदर्भ बिंदु निर्धारित नहीं करता है। यदि आप वेब प्रोग्राम करते हैं, तो "धीमी" का अर्थ आपके लिए उच्च प्रदर्शन क्लस्टर के डेवलपर या एम्बेडेड सिस्टम के डेवलपर की तुलना में कुछ अलग है। खैर, अब जब हम सभी धक्कों से गुजरे हैं और सभी प्रकार के प्रदर्शन परीक्षण किए हैं, तो मैं तीन बेंचमार्क को नाम दूंगा जो उपयोगी और अपेक्षाकृत सही हैं।
यदि आप एक वेब डेवलपर हैं, iPhone 4S नाइट्रो को IE8 के रूप में देखें, उनका प्रदर्शन उसी वर्ग के बारे में है। इससे आपको कोड लिखने का तरीका पता चल जाएगा। JS का उपयोग बहुत सावधानी से किया जाना चाहिए, या आप इसे ओवरक्लॉक करने वाले विभिन्न प्लेटफॉर्म-विशिष्ट हैक्स में आएंगे। कुछ एप्लिकेशन को केवल लोकप्रिय ब्राउज़रों में भी प्रभावी रूप से लागू नहीं किया जा सकता है।
यदि आप एक x86 C / C ++ डेवलपर हैं, तो iPhone 4S पर एक C वातावरण के रूप में वेब एप्लिकेशन विकसित करने पर ध्यान दें जो डेस्कटॉप वातावरण की तुलना में 50 गुना धीमा है। एआरएम आर्किटेक्चर एक परिमाण और जावास्क्रिप्ट के आदेश से गति को 5 गुना कम कर देता है। या आप एक गैर-जावास्क्रिप्ट वातावरण में विकास के पेशेवरों और विपक्षों का वजन कर सकते हैं, जो डेक्सटॉप की तुलना में परिमाण धीमी करने का एक आदेश है।
यदि आप एक जावा, रूबी, पायथन, सी # डेवलपर हैं, iPhone 4S पर वेब अनुप्रयोगों को विकसित करने के लिए निम्नानुसार देखें। यह एक ऐसा कंप्यूटर है जो आपकी अपेक्षा से कम परिमाण का एक क्रम है (क्योंकि एआरएम) और प्रदर्शन तेजी से गिरता है यदि मेमोरी का उपयोग किसी भी समय 35 एमबी से अधिक हो जाता है, क्योंकि यह इस तरह से कचरा संग्रहकर्ता इस मंच पर व्यवहार करता है। इसके अलावा, यदि मेमोरी का आवंटन 213 एमबी से अधिक है, तो एप्लिकेशन बंद हो जाएगा। और कोई भी व्यक्ति जानबूझकर, निष्पादन के समय इस विषय पर यह जानकारी नहीं देगा। आह, हाँ, और लोग फ़ोटो और वीडियो को संसाधित करने वाले एप्लिकेशन बनाने के लिए कहेंगे।

यह एक वास्तविक बड़ा लेख है

यहां यह याद रखना चाहिए:
* 2013 में, जावास्क्रिप्ट का उपयोग मोबाइल उपकरणों पर फोटो प्रसंस्करण जैसे अनुप्रयोगों को बनाने के लिए बहुत धीमा है:
- यह मूल कोड की तुलना में 5 गुना धीमा है;
- यह IE8 के लिए तुलनीय है;
- यह x86 C / C ++ से लगभग 50 गुना धीमा है;
- यह सर्वर-साइड Java / Ruby / Python / C # से लगभग 10 गुना धीमा है, अगर प्रोग्राम 35 MB से अधिक मेमोरी आवंटित नहीं करता है और मेमोरी के आगे आवंटन के साथ बहुत धीमा हो जाता है;
* डेस्कटॉप पर प्रोसेसर के प्रदर्शन को बढ़ाने के लिए इसे ओवरक्लॉक करने का सबसे यथार्थवादी तरीका है। शायद ऐसा होगा, लेकिन निकट भविष्य में नहीं;
* हाल ही में भाषा में तेजी नहीं आई है, और इसके डेवलपर्स का दावा है कि भाषा और एपीआई को बनाए रखने के दौरान, प्रदर्शन मूल कोड के साथ कभी नहीं पकड़ेगा;
* उपलब्ध स्मृति की सीमित मात्रा के साथ कचरा कलेक्टर बहुत धीमा है। यह डेस्कटॉप या सर्वर की तुलना में बहुत बुरा व्यवहार करता है;
* प्रत्येक मोबाइल डेवलपर, चाहे वह कचरा संग्रह का उपयोग करता हो या नहीं, ध्यान से स्मृति के साथ काम करने के बारे में सोचता है;
* मोबाइल उपकरणों पर मेमोरी खपत का अनुमान लगाने की कोशिश करने के बावजूद जावास्क्रिप्ट वर्तमान में मौलिक रूप से है;
* भले ही वे इस अवसर को देना चाहते हों, अनुभव से पता चलता है कि यह बहुत मुश्किल होगा;
* Asm.js के लिए आशा है, लेकिन यह JS की तरह कुछ गतिशील की तुलना में C \ C ++ जैसा दिखता है।

अस्वीकृति की बढ़ती स्तर

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