समय से पहले अनुकूलन के जाल में न पड़ें

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



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

खेल GeoArena ऑनलाइन

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


खेल GeoArena ऑनलाइन


खेल GeoArena ऑनलाइन

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

Fast.js पुस्तकालय

इंटरनेट पर थोड़ी खोज करने के बाद, मैंने fast.js लाइब्रेरी की खोज की। यह "बहुत तेज जावास्क्रिप्ट कार्यक्रमों के विकास को सरल बनाने के उद्देश्य से सूक्ष्म-अनुकूलन का संग्रह था।" इस लाइब्रेरी को Array.prototype.forEach () जैसे बिल्ट-इन मानक तरीकों के तेजी से कार्यान्वयन की उपलब्धता के द्वारा त्वरित किया गया था।

मुझे यह बेहद दिलचस्प लगा। GeoArena ने कई सरणियों का उपयोग किया, सरणियों के साथ कई ऑपरेशन किए, इसलिए fast.js का उपयोग करने से मुझे खेल को गति देने में बहुत मदद मिल सकती है। forEach() प्रदर्शन अध्ययन के निम्नलिखित परिणाम तेजी से शामिल होने के लिए README में शामिल किए गए थे।

 Native .forEach() vs fast.forEach() (10 items)  ✓ Array::forEach() x 8,557,082 ops/sec ±0.37% (97 runs sampled)  ✓ fast.forEach() x 8,799,272 ops/sec ±0.41% (97 runs sampled)  Result: fast.js is 2.83% faster than Array::forEach(). 

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

यहाँ ऐसे सरणियों के कुछ सरल उदाहरण दिए गए हैं:

 //  -  :   1  . const sparse1 = [0, , 1]; console.log(sparse1.length); // 3 //  -   const sparse2 = []; // ...   - .   0 - 4    . sparse2[5] = 0; console.log(sparse2.length); // 6 

यह समझने के लिए कि पुस्तकालय विरल सरणियों के साथ सामान्य रूप से काम क्यों नहीं कर सकता है, मैंने इसके स्रोत कोड को देखा। यह पता चला कि forEach() fast.js में कार्यान्वयन छोरों पर आधारित है। forEach() का त्वरित कार्यान्वयन forEach() विधि कुछ इस तरह दिखाई देगी:

 //     . function fastForEach(array, f) {  for (let i = 0; i < array.length; i++) {    f(array[i], i, array);  } } const sparseArray = [1, , 2]; const print = x => console.log(x); fastForEach(sparseArray, print); //  print() 3 . sparseArray.forEach(print); //  print()  2 . 

fastForEach() विधि के लिए एक कॉल तीन मानों को fastForEach() करता है:

 1 undefined 2 

कॉलिंग sparseArray.forEach() केवल दो मूल्यों के समापन की ओर जाता है:

 1 2 

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

इस बिंदु पर, मुझे बस fast.js. पर एक त्वरित परीक्षा देनी चाहिए मुझे लाइब्रेरी स्थापित करनी चाहिए, एरियर ऑब्जेक्ट के मानक तरीकों को fast.js से विधियों में बदलना चाहिए और खेल के प्रदर्शन का परीक्षण करना चाहिए। लेकिन इसके बजाय, मैं पूरी तरह से अलग दिशा में चला गया।

मेरा विकास कहा जाता है

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

यह वह विचार था जिसने मुझे एक सरल विचार के लिए प्रेरित किया, जो कि एक संकलक का निर्माण करना था, जिसे मैंने बेशर्मी से तेज .js कहा। मैंने इसे fast.js. के बजाय इसका उपयोग करने की योजना बनाई उदाहरण के लिए, यहाँ स्रोत कोड स्निपेट है:

 //   const arr = [1, 2, 3]; const results = arr.map(e => 2 * e); 

तेजी से .js संकलक इस कोड को निम्न में बदल देगा - तेज, लेकिन इससे भी बदतर:

 //      faster.js const arr = [1, 2, 3]; const results = new Array(arr.length); const _f = (e => 2 * e); for (let _i = 0; _i < arr.length; _i++) {  results[_i] = _f(arr[_i], _i, arr); } 

Fast.js के निर्माण को एक ही विचार द्वारा प्रेरित किया गया था जो कि fast.js. अर्थात्, हम विरल सरणियों के समर्थन की अस्वीकृति के कारण प्रदर्शन की सूक्ष्म-अनुकूलन के बारे में बात कर रहे हैं।

पहली नज़र में, fast.js मुझे एक बेहद सफल विकास लग रहा था। यहाँ कुछ परिणाम तेजी से हैं। जेएस प्रदर्शन अध्ययन:

   array-filter large    ✓ native x 232,063 ops/sec ±0.36% (58 runs sampled)    ✓ faster.js x 1,083,695 ops/sec ±0.58% (57 runs sampled) faster.js is 367.0% faster (3.386μs) than native  array-map large    ✓ native x 223,896 ops/sec ±1.10% (58 runs sampled)    ✓ faster.js x 1,726,376 ops/sec ±1.13% (60 runs sampled) faster.js is 671.1% faster (3.887μs) than native  array-reduce large    ✓ native x 268,919 ops/sec ±0.41% (57 runs sampled)    ✓ faster.js x 1,621,540 ops/sec ±0.80% (57 runs sampled) faster.js is 503.0% faster (3.102μs) than native  array-reduceRight large    ✓ native x 68,671 ops/sec ±0.92% (53 runs sampled)    ✓ faster.js x 1,571,918 ops/sec ±1.16% (57 runs sampled) faster.js is 2189.1% faster (13.926μs) than native 

पूर्ण परीक्षा परिणाम यहां देखे जा सकते हैं । उन्हें 15-इंच मैकबुक प्रो 2018 पर नोड v8.16.1 में आयोजित किया गया था।

क्या मेरा विकास मानक कार्यान्वयन से 2000% तेज है? उत्पादकता में इतनी गंभीर वृद्धि, बिना किसी संदेह के, किसी भी कार्यक्रम पर सबसे मजबूत सकारात्मक प्रभाव डाल सकती है। है न?
नहीं, सच नहीं है।

एक साधारण उदाहरण पर विचार करें।

• कल्पना कीजिए कि औसत GeoArena खेल में गणना के 5,000 मिलीसेकंड (ms) की आवश्यकता होती है।
• Fast.js संकलक औसत तरीकों से सरणी विधियों के निष्पादन को 10 गुना बढ़ाता है (यह अनुमानित अनुमान है, इसके अलावा, यह बहुत कम है; अधिकांश वास्तविक अनुप्रयोगों में दोहरा त्वरण भी नहीं है)।

और यहाँ यह सवाल है कि क्या वास्तव में हमारा हित है: "सरणी विधियों के कार्यान्वयन पर इन 5000 एमएस का क्या हिस्सा खर्च होता है?"।

मान लीजिए आधा। यही है, 2500 ms सरणी तरीकों पर खर्च किया जाता है, बाकी 2500 ms बाकी सब चीजों पर। यदि ऐसा है, तो fast.js का उपयोग करने से एक विशाल प्रदर्शन को बढ़ावा मिलेगा।


सशर्त उदाहरण: कार्यक्रम का निष्पादन समय बहुत कम हो गया है

नतीजतन, यह पता चला है कि कुल कम्प्यूटेशनल समय 45% तक कम हो गया है।

दुर्भाग्य से, ये सभी तर्क बहुत, वास्तविकता से बहुत दूर हैं। GeoArena, ज़ाहिर है, कई सरणी विधियों का उपयोग करता है। लेकिन विभिन्न कार्यों के लिए कोड निष्पादन समय का वास्तविक वितरण निम्नलिखित में से कुछ जैसा दिखता है।


हर्ष वास्तविकता

दुख की बात है, मैं क्या कह सकता हूं।

यह वही गलती है जिसके बारे में डोनाल्ड नथ ने चेतावनी दी थी। मैंने अपना प्रयास उस स्थिति में नहीं रखा, जो उन्हें लागू करना चाहिए था, और जब वह करने लायक था, तो मैंने ऐसा नहीं किया।

यहाँ सरल गणित खेलने में आता है। यदि कोई कार्यक्रम के निष्पादन के समय का केवल 1% लेता है, तो उसे अनुकूलित करने से सर्वोत्तम मामले में, उत्पादकता में केवल 1% की वृद्धि होगी।

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

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

परिणाम

यदि आप तेजी से प्रयोग करने में रुचि रखते हैं। तो आप इस डेमो पर एक नज़र डाल सकते हैं। आपको जो परिणाम मिलते हैं, वह आपके डिवाइस और ब्राउज़र पर निर्भर करता है। यहाँ, उदाहरण के लिए, 15 इंच के मैकबुक प्रो 2018 पर क्रोम 76 में क्या हुआ।


Faster.js परीक्षण के परिणाम

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

• का उपयोग करते हुए तेजी से .js एक विशिष्ट खेल में मुख्य खेल चक्र के निष्पादन को लगभग 1% तक गति प्रदान करता है।
• Fast.js के उपयोग के कारण, गेम के बंडल का आकार 0.3% बढ़ गया। इससे गेम पेज का लोड थोड़ा धीमा हो गया। बंडल का आकार इस तथ्य के कारण बड़ा हो गया है कि fast.js मानक शॉर्ट कोड को तेज़ी से परिवर्तित करता है, लेकिन अब कोड भी।

सामान्य तौर पर, fast.js के पास इसके पेशेवरों और विपक्ष हैं, लेकिन मेरा यह विकास GeoArena के प्रदर्शन पर बहुत प्रभाव नहीं डालता है। मुझे यह पहले ही समझ आ जाता अगर मैं पहले खेल को तेज करने के लिए परेशान करता।

मेरी कहानी आपको एक चेतावनी के रूप में काम कर सकती है।

प्रिय पाठकों! क्या आप समय से पहले अनुकूलन के जाल में पड़ गए?