गज़क जोड़ें: + 200% उत्पादकता

हेलो, हैबर।



पिछली बार मैंने आपको बताया था कि हमने जावास्क्रिप्ट में रॉ कन्वर्टर कैसे लिखा है, और आपने मुझे बताया कि यह धीरे-धीरे काम करता है। आज मैं इस बारे में बात करना चाहता हूं कि कैसे हमने अपने कच्चे । Pics.io को लगभग 3 गुना तेज किया। मैं प्रत्येक चरण के विवरण के साथ कोड की चादरों को पोस्ट नहीं करूंगा, मैं उन सामान्य दृष्टिकोणों के बारे में सामान्य तरीके से बताने की कोशिश करूंगा जो हमने उपयोग किए थे। मैंने DOM तक पहुंच के बारे में नहीं लिखने, HTTP अनुरोधों की संख्या कम करने, फाइलों को चिपकाने और कम करने, सर्वर पर कम्प्रेशन विकल्प आदि के बारे में भी निर्णय लिया। यह सब तकनीकी काम है जिसके बारे में उन्होंने अच्छा और बहुत कुछ लिखा है।

यह सब कैसे शुरू हुआ

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

प्रौद्योगिकी अनुकूलन

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

SIMD (एकल निर्देश एकाधिक डेटा)

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

WebCL

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

WebWorkers

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



सामान्य तौर पर, सभी में पाया गया, सबसे अधिक काम करने वाले वेबवर्कर्स थे, जो अब हमारे साथ raw.pics.io पर काम करते हैं।

एल्गोरिथम अनुकूलन

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

संरचनाओं और डेटा प्रकारों का अनुकूलन

टाइप किए गए एरे

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

सरल संरचना

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

भाषा स्तर अनुकूलन

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



यह भी समझने योग्य है कि आपके चक्रों में यह अपरिवर्तनीय है और प्रत्येक पुनरावृत्ति में नहीं बदलता है। इन आक्रमणकारियों को लूप से बाहर निकालना होगा। एक सरल उदाहरण :

//   for(var i=0; i<items.length; i++) { //  ... } //     var size = items.length; for(var i=0;i<size; i++){ //  ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

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



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

प्लेटफ़ॉर्म स्तर का अनुकूलन

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

धारणा अनुकूलन

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

कब खत्म करना है

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

अंतभाषण

उपयोगी उपकरण

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

विकल्पों का परीक्षण कैसे करें

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



सामान्य तौर पर, अनुकूलन करने के लिए या नहीं (और सबसे महत्वपूर्ण बात यह है कि), प्रत्येक मामले में निर्णय लेना आवश्यक है और यह निर्णय कई कारकों पर निर्भर करता है जो संरचना के लिए कठिन हैं। उपरोक्त तरीकों के संयोजन से, हम कई बार RAW फ़ाइलों के रूपांतरण को गति देने में सक्षम थे, जो पहले तो लगभग असंभव लग रहा था। और इसका मतलब है कि आप सफल होंगे।