प्रोजेक्ट टाइम ऑप्टिमाइज़ेशन

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

यह "सहेजें" बटन पर प्रत्येक क्लिक के बाद प्रतीक्षा करने के लिए लगभग 14 सेकंड है।

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



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

प्रोजेक्ट बनाने में लगने वाले समय को मापना

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

const webpackConfig = require('./webpack.config') const SpeedMeasurePlugin = require('speed-measure-webpack-plugin') const smp = new SpeedMeasurePlugin({   disable: !process.env.MEASURE, }) module.exports = smp.wrap(webpackConfig) 

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


स्पीड-माप-वेबपैक-प्लगइन के साथ उत्पन्न रिपोर्ट

एक परियोजना के प्रारंभिक निर्माण समय में सुधार

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

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

यहाँ एक उदाहरण है:

 {  rules: [    {      test: /\.jsx?$/,      use: [        'cache-loader',        'babel-loader',      ],    },    {      test: /\.scss$/,      use: [        'style-loader',        'cache-loader',        'css-loader',        'postcss-loader',        'sass-loader',      ],    },  ] } 

सीएसएस-लोडर (सीएसएस के लिए) से पहले और बैबल-लोडर (जेएस के लिए) से पहले cache-loader जोड़ना हमें परियोजना के प्रारंभिक निर्माण पर खर्च किए गए समय से लगभग 75 सेकंड निकालने की अनुमति देता है।

अब हम reassembly समय पर काम करते हैं। हम इस समय को बदलकर devtool संपत्ति में सुधार करने का प्रयास करेंगे।

वेबपैक कोड कार्ड

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

दूसरे शब्दों में, devtool संपत्ति को संशोधित करने से प्रभावित होता है कि परियोजना के निर्माण के बाद कौन सा कोड कार्ड डेवलपर को उपलब्ध होगा। और यह बदले में, इस तरह के कोड कार्ड को बनाने में कितना समय लेता है, इस पर निर्भर करता है।

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

 {  devtool: process.env.NODE_ENV === 'development'    ? 'eval-source-map'    : 'source-map' } 

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

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

यहाँ है कि क्या babel.config.js चाहिए, यदि आप किसी ऐसे राज्य में कोड babel.config.js करने का निर्णय लेते हैं जो विभिन्न ब्राउज़रों के नवीनतम संस्करणों के लिए स्पष्ट है:

 module.exports = {  presets: [    [      '@babel/preset-env',      {        targets: [          'last 1 chrome version',          'last 1 safari version',          'last 1 firefox version',        ].join(', '),      },    ],  ],  // ... } 

वह सब है। तीन सरल कदम, और हमारी परियोजना का निर्माण समय बहुत कम हो गया था।

मैं यह नोट करना चाहूंगा कि जो कोई इसी तरह की समस्या को हल करना शुरू करता है, उसे पहले वेबपैक प्रलेखन को देखने और इसे ठीक से पढ़ने की इच्छा हो सकती है। हालाँकि, यह ज्ञान का एकमात्र स्रोत नहीं है।

मुझे परियोजनाओं के निर्माण के बारे में मूल्यवान जानकारी खोजने के लिए एक और दृष्टिकोण मिला। इस दृष्टिकोण ने व्यवहार में खुद को साबित कर दिया है। इसमें मौजूदा ओपन सोर्स प्रोजेक्ट्स की webpack.config फाइलों का विश्लेषण webpack.config । विशेष रूप से, CreateReactApp प्रोजेक्ट फ़ाइल। पूरी तरह से इस फ़ाइल को पढ़कर, आप बहुत सारी उपयोगी चीजों का पता लगा सकते हैं।

परिणाम

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

प्रिय पाठकों! क्या आप अपनी परियोजनाओं के निर्माण समय का अनुकूलन करते हैं?