फ्रंट एंड परफॉर्मेंस: पार्सिंग महत्वपूर्ण मेट्रिक्स

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

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

सबसे पहले, हम यह निर्धारित करेंगे कि फ्रंट-एंड प्रदर्शन क्या है, और फिर हम इसे मापने के तरीके पर आगे बढ़ेंगे। इसलिए, जैसा कि मैंने कहा, हम कुछ ऑप्स / सेकंड को नहीं मापेंगे, हमें वास्तविक डेटा की आवश्यकता है जो इस सवाल का जवाब दे सके कि इसके काम के प्रत्येक चरण में हमारी परियोजना के साथ वास्तव में क्या होता है। ऐसा करने के लिए, हमें मीट्रिक के निम्नलिखित सेट की आवश्यकता है:

• डाउनलोड गति;
• पहले प्रतिपादन और अन्तरक्रियाशीलता का समय (इंटरएक्टिव का समय);
• उपयोगकर्ता कार्यों की प्रतिक्रिया की गति;
• स्क्रॉलिंग और एनिमेशन के लिए एफपीएस;
• आवेदन आरंभीकरण;
• यदि आपके पास एक एसपीए है, तो आपको मार्गों के बीच स्विच करने पर खर्च किए गए समय को मापने की आवश्यकता है;
• स्मृति और यातायात की खपत;
• और ... अभी के लिए पर्याप्त है।

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

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

PerfKeeper

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

अब मैं यहां एपीआई पेंट नहीं करूंगा, मैंने इसके लिए प्रलेखन नहीं लिखा था, और लेख उस बारे में नहीं है, लेकिन मैं मैट्रिक्स कैसे इकट्ठा करना जारी रखूंगा।

पेज डाउनलोड स्पीड

जैसा कि मैंने पहले ही कहा था, आप प्रदर्शन गति से डाउनलोड गति का पता लगा सकते हैं। यह आपको पेज लोडिंग की शुरुआत से पूर्ण चक्र का पता लगाने की अनुमति देगा (DNS को हल करने का समय, HTTP हैंडशेक को स्थापित करना, अनुरोध को संसाधित करना) से पूर्ण पृष्ठ लोडिंग (डोमरेड्डी और ओनलॉड):



परिणामस्वरूप, आपको मैट्रिक्स का निम्नलिखित सेट प्राप्त करना चाहिए:
@ Perf-tools / keeper के लिए नेविगेशन एक्सटेंशन का एक उदाहरण।

लेकिन यह पर्याप्त नहीं है, हमें केवल मूल मूल्य मिले और अभी भी नहीं पता कि वास्तव में इतना समय क्या लगा। और यह पता लगाने के लिए, आपको HTML मेट्रिक्स में भी भरना होगा।

जैसा कि मैंने पहले ही कहा था, मैं PerfKeeper का उपयोग करके उदाहरण दिखाऊंगा , इसलिए पहली बात यह है कि <hed/> PerfKeeper में ही इनलाइन है (2.5 Kb) और आगे:

परिणामस्वरूप, आप सांत्वना में ऐसी सुंदरता देखेंगे:


यह माप का एक उत्कृष्ट दादाजी तरीका है, 100% काम करता है। लेकिन दुनिया अभी भी खड़ा नहीं है, और अधिक सटीक माप के लिए हमारे पास अब संसाधन समय एपीआई है (और यदि संसाधन आपकी मदद करने के लिए एक अलग समय-अनुमति-मूल डोमेन पर हैं)।

और यहां पृष्ठ की प्रारंभिक लोडिंग के दौरान क्लासिक त्रुटियों के बारे में बात करने लायक है, अर्थात्:

• GZip और HTTP / 2 की कमी (हाँ, यह अभी भी आम है);
• फोंट का अनुचित उपयोग (कभी-कभी एक फ़ॉन्ट केवल एक हेडर के लिए या यहां तक ​​कि पाद लेख 0_o में एक फोन नंबर के लिए जुड़ा हुआ है);
• CSS / JS बंडल बहुत सामान्य है।

पृष्ठ लोडिंग को अनुकूलित करने के तरीके:

• GZip के बजाय Brotli (या यहां तक ​​कि SDCH) का उपयोग करें, HTTP / 2 को सक्षम करें;
• केवल आवश्यक सीएसएस (महत्वपूर्ण) लीजिए और सीएसएसओ के बारे में मत भूलना;
• न्यूनतम कोर बंडल को अलग करके जेएस बंडल के आकार को कम करें, और बाकी मांग पर लोड करें, अर्थात। अतुल्यकालिक रूप से;
• जेएस और सीएसएस को गैर-ब्लॉकिंग मोड में लोड करें, गतिशील रूप से /> <sript src="..."/> , आदर्श रूप से जेएस को मुख्य सामग्री के बाद लोड करें;
• पीएनजी के बजाय एसवीजी का उपयोग करें, और यदि जेएस के साथ संयुक्त है, तो यह अनावश्यक एक्सएमएल से छुटकारा पायेगा (उदाहरण के लिए, फ़ॉन्ट-कमाल की तरह);
• दोनों छवियों और iframes के लिए आलसी लोडिंग का उपयोग करें (इसके अलावा, निकट भविष्य में देशी समर्थन दिखाई देगा)।

पहला प्रतिपादन समय और अन्तरक्रियाशीलता (TTI)

लोड करने के बाद अगला चरण वह क्षण होता है जब उपयोगकर्ता ने परिणाम देखा, और इंटरफ़ेस इंटरैक्टिव मोड में चला गया। इसके लिए हमें Performance Paint Timing और PerformanceObserver की आवश्यकता है ।

पहला वाला सरल है, हम performance.getEntriesByType('paint') कहते हैं performance.getEntriesByType('paint') और हमें दो मैट्रिक्स मिलते हैं:

• पहला-पेंट - पहला प्रतिपादन;
• पहला-विवादास्पद-पेंट - और पहला पहला रेंडर।

@ Perf-tools / कीपर के लिए पेंट एक्सटेंशन का एक उदाहरण।

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

  // TTI let ttiLastEntry: PerformanceEntry | undefined; let ttiPerfObserver: PerformanceObserver; try { ttiPerfObserver = new PerformanceObserver((list) => { ttiLastEntry = list.getEntries().pop(); }); ttiPerfObserver.observe({ entryTypes: ['longtask'], }); } catch (_) {} domReady(() => { // TTI Check if (ttiPerfObserver) { let tti: number; const check = () => { if (ttiLastEntry) { tti = ttiLastEntry.startTime + ttiLastEntry.duration; if (now() - tti >= options.ttiDelay) { //  logntask  ,  , //     ;] send('tti', 'value', 0, tti); ttiPerfObserver.disconnect(); } else { setTimeout(check, options.ttiDelay); } } else if (tti) { send('tti', 'value', 0, tti); ttiPerfObserver.disconnect(); } else { //   logntask,         , //  ,       DOMReady! tti = now(); setTimeout(check, 500); } } //   check(); } }); 

@ Perf-tools / कीपर के लिए प्रदर्शन विस्तार का एक उदाहरण।

इन मूल मैट्रिक्स के अलावा, आपकी एप्लिकेशन तत्परता मीट्रिक भी आवश्यक है, अर्थात आपके कोड में कहीं ऐसा होना चाहिए:

 Import { system } from '@perf-tools/keeper'; export function applicationBoot(el, data) { const app = new Application(el, data); //     app.ready(() => { system.add('application-ready', 0, system.perf.now()); // ️application-ready: 3074.000ms }); return app; } 

उपयोगकर्ता कार्यों के लिए प्रतिक्रिया दर

मैट्रिक्स के लिए एक बहुत बड़ा क्षेत्र है और वे बहुत ही अलग-अलग हैं, इसलिए मैं उन दो बुनियादी लोगों के बारे में बात करूँगा जो किसी भी परियोजना के लिए उपयुक्त हैं, जैसे:

प्रथम-घटना - पहली घटना का समय, उदाहरण के लिए, पहला क्लिक (जहां उपयोगकर्ता को रोका गया है), यह मीट्रिक विशेष रूप से सभी प्रकार के खोज परिणामों, उत्पादों की सूची, समाचार फ़ीड आदि के लिए प्रासंगिक है। इसके साथ, आप यह नियंत्रित कर सकते हैं कि आपकी क्रियाओं से प्रतिक्रिया समय और उपयोगकर्ता का प्रवाह कैसे हो (परिवर्तन: डिज़ाइन / नई सुविधाएँ / अनुकूलन इत्यादि) परिवर्तन
@ Perf-tools / कीपर के लिए प्रदर्शन विस्तार का एक उदाहरण।

विलंबता - कुछ घटनाओं को संसाधित करते समय देरी, उदाहरण के लिए: click , input , submit , scroll , आदि।

देरी को मापने के लिए, बस capture = true साथ window पर ईवेंट हैंडलर requestAnimationFrame और requestAnimationFrame उपयोग करें। अंतर की गणना requestAnimationFrame लिए requestAnimationFrame , यह देरी होगी:

 window.addEventListener(eventType, ({target}) => { const start = now(); requestAnimationFrame(() => { const latency = now() - start; if (latency >= minLatency) { // …. } }); }, true); 

जब एक क्लिक पर एक फाइबोनैचि संख्या की गणना की जाती है तो @ perf-tools / keeper के लिए प्रदर्शन विस्तार का एक उदाहरण।

स्क्रॉलिंग और एनिमेशन करते समय एफपीएस

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

वास्तव में, वास्तव में, हम सिर्फ एक पारदर्शी div (1x1px) बनाते हैं, transition: left 300ms linear जोड़ते हैं transition: left 300ms linear और इसे एक कोने से दूसरे कोने में चलाते हैं, और यह एनिमेट करते हुए, requestAnimationFrame माध्यम से requestAnimationFrame वास्तविक बाईं जाँच करते हैं, और यदि नई लंबाई पिछले एक से भिन्न होती है, तो फिर प्रदान किए गए फ़्रेमों की संख्या में वृद्धि करें (अन्यथा हमारे पास एक एफपीएस ड्राडाउन है)।

और यह सब नहीं है, यदि आप एफएफ का उपयोग करते हैं, तो बस mozPaintCount है , जो प्रदान किए गए फ़्रेम की संख्या के लिए जिम्मेदार है, अर्थात्। हमें "डीओ" याद है, और transitionend हम अंतर की गणना करते हैं।

कुल, बिना किसी वार्म अप के, हम यह सुनिश्चित करने के लिए जानते हैं कि ब्राउज़र फ़्रेम को फिर से बनाता है या नहीं।

वे जल्द ही एक सामान्य एपीआई का वादा करते हैं: http://wicg.imtqy.com/frame-timing/@ Perf-tools / कीपर के लिए एफपीएस एक्सटेंशन का एक उदाहरण।

स्क्रॉलिंग अनुकूलन:

• सरलतम बात यह है कि स्क्रॉल पर कुछ भी नहीं करना है, या requestAnimationFrame माध्यम से विलंब निष्पादन requestIdleCallback ।
• बहुत सावधानी से pointer-events: none उपयोग करें pointer-events: none , इसे चालू और बंद करने का विपरीत प्रभाव हो सकता है, इसलिए pointer-events और बिना उपयोग किए ए / बी प्रयोग करना बेहतर है;
• वर्चुअलाइज्ड सूचियों के बारे में मत भूलना, लगभग सभी दृश्य इंजनों में अब ऐसे घटक हैं, लेकिन फिर से, सावधान रहें, ऐसी सूची के तत्व यथासंभव सरल होने चाहिए या "डमीज़" का उपयोग करें जो स्क्रॉलिंग पूरी होने के बाद वास्तविक तत्वों के साथ बदल दिए जाएंगे। यदि आप स्वयं एक वर्चुअलाइज्ड सूची लिखते हैं, तो कोई आंतरिक HTML और DOM पुनर्चक्रण के बारे में मत भूलना (यह तब है जब आप हर छींक के लिए DOM तत्व नहीं बनाते हैं, लेकिन उनका पुन: उपयोग करें)।

आवेदन आरंभीकरण

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

• प्रत्येक व्यसन को हल करने में कितना समय लगा;
• आवेदन प्राप्त करने और डेटा तैयार करने का समय;
• ब्लॉक द्वारा विवरण के साथ आवेदन प्रस्तुत करना।

यानी आउटपुट पर, आपको ऐसे मेट्रिक्स प्राप्त करने चाहिए, जिनके द्वारा आप ठीक-ठीक पता लगा सकते हैं कि आपका ड्राडाउन किस चरण में चल रहा है।

यदि आपके पास एसपीए है, तो आपको रूटिंग समय को मापने की आवश्यकता है

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

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

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

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

मेमोरी और ट्रैफ़िक की खपत

स्मृति से शुरू करते हैं । और यहाँ हम एक बड़ी निराशा की प्रतीक्षा कर रहे हैं। फिलहाल गैर-मानकीकृत (केवल क्रोम) प्रदर्शन है। यह हास्यास्पद रूप से कम संख्या देता है। लेकिन फिर भी उन्हें मापा जाना चाहिए और देखना चाहिए कि समय के साथ "प्रवाह" कैसे होता है:@ Perf-tools / कीपर के लिए मेमोरी एक्सटेंशन का एक उदाहरण

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

• क्या प्रोटोकॉल का उपयोग किया जाता है (HTTP / 1, HTTP / 2, आदि);
• लोड किए गए संसाधनों के प्रकार;
• उन्हें डाउनलोड करने में कितना समय लगा;
• आकार, इसके अलावा, आप समझ सकते हैं कि संसाधन नेटवर्क पर लोड है या कैश से लिया गया है।

@ Perf-tools / कीपर के लिए संसाधन विस्तार का एक उदाहरण।

ट्रैफिक काउंट क्या देता है?

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

खैर, इस विषय पर मेरे सहयोगी इगोर ड्रूज़िनिन की एक कैच-अप रिपोर्ट: आवेदन की गुणवत्ता का मूल्यांकन : निगरानी खपत

एनालिटिक्स

हम मैट्रिक्स सेट करते हैं, और फिर क्या? और फिर उन्हें कहीं भेजने की आवश्यकता है। और यहां या तो आप से कुछ ग्रेफाइट लेते हैं , या शुरुआत के लिए, आप व्यक्तिगत लाभ के लिए डेटा एकत्रीकरण के लिए Google Analytics या समान का उपयोग कर सकते हैं।

और यह मत भूलो, यह केवल एक शेड्यूल पाने के लिए पर्याप्त नहीं है, सभी महत्वपूर्ण मैट्रिक्स के लिए प्रतिशत होना चाहिए जो आपको समझने की अनुमति देता है, उदाहरण के लिए, परियोजना का कितना प्रतिशत दर्शक <1s, <2s, <3s, 5s, 5s + आदि के लिए लोड कर रहा है।

उच्च-प्रदर्शन कोड लिखना

सबसे पहले, मैं यहाँ कुछ सार्थक लिखना चाहता था, वे कहते हैं कि WebWorker का उपयोग करें, requestIdleCallback या कुछ विदेशी मत भूलना, उदाहरण के लिए, SharedWorker या ServiceWorker का उपयोग करके ब्राउज़र टैब के माध्यम से रनटाइम कैश के माध्यम से (जो केवल कैशिंग के बारे में नहीं है, यदि वह है)। लेकिन यह सब बहुत सार है, और कई विषयों को असंभवता के लिए पीटा जाता है, इसलिए बस निम्नलिखित लिखें:

1. प्रारंभ में अपने कोड को मीट्रिक के साथ कवर करें जो इसके प्रदर्शन को मापेगा।
2. Jsperf वाले मानदंड पर विश्वास न करें। उनमें से अधिकांश को खराब तरीके से लिखा गया है, और बस संदर्भ से बाहर ले जाया गया है। सर्वश्रेष्ठ बेंचमार्क प्रोजेक्ट पर वास्तविक मीट्रिक है, जिसके अनुसार आप अपने कार्यों का प्रभाव देखेंगे।
3. उत्पादकता, या बल्कि वेबर-फेचनर कानून की धारणा के बारे में याद रखें। अर्थात्, यदि आपने अनुकूलन शुरू किया है, तो बदलावों को तब तक रोल आउट न करें जब तक कि यह कम से कम 20% तक बेहतर न हो जाए, अन्यथा उपयोगकर्ता बस नोटिस नहीं करेंगे। कानून विपरीत दिशा में भी काम करता है।
4. भय नियमित, विशेष रूप से उत्पन्न। वे न केवल ब्राउज़र को लटका सकते हैं, बल्कि एक्सएसएस भी प्राप्त कर सकते हैं, यही कारण है कि हमारे मेल में केवल उनका उपयोग करके HTML को पार्स करने से मना किया जाता है, केवल एक डोम बाईपास के माध्यम से।
5. आपको एक या किसी अन्य समूह में मान दर्ज करने के लिए सरणियों का उपयोग करने की आवश्यकता नहीं है, इसके लिए एक object या Set (उदाहरण के लिए, successSteps.includes(currentStep) जरूरी successSteps.includes(currentStep) कि उसके successSteps.hasOwnProperty(currentStep) ), O (1) सब कुछ है।
6. अभिव्यक्ति "समयपूर्व अनुकूलन सभी बुराइयों की जड़ है" जो कुछ भी आप चाहते हैं उसे लिखने के बारे में नहीं है। यदि आप जानते हैं कि कैसे सबसे अच्छा है, तो बेहतर ढंग से लिखें।

ध्यान देने के लिए आपका धन्यवाद, यह सब, माप, विश्लेषण और उपयोग करें PerfKeeper ( लाइव उदाहरण ), साथ ही साथ मेरे गितुब और ट्विटर , प्रश्नों के मामले में!