अलग-अलग जावास्क्रिप्ट घटकों द्वारा उत्पन्न सीपीयू लोड का विश्लेषण

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

इसकी आवश्यकता क्यों है?

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

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

प्रदर्शन संकेतक

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

विचार

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

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

अच्छी बात यह है कि इस तरह के अध्ययन एक वास्तविक ब्राउज़र में किए जा सकते हैं, उदाहरण के लिए, Puppeteer। यह एक उपकरण है जो आपको Node.js. से उपयोगकर्ता इंटरफ़ेस के बिना ब्राउज़र को नियंत्रित करने की अनुमति देता है

शोध के लिए खोज कोड

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

"स्टाइल गाइड" क्या है? यह आमतौर पर एक वेब एप्लिकेशन है जो उपयोगकर्ता इंटरफ़ेस तत्वों के सभी घटकों या "बिल्डिंग ब्लॉक्स" को प्रदर्शित करता है जो डेवलपर के लिए उपलब्ध हैं। यह या तो तृतीय-पक्ष घटकों का एक निश्चित पुस्तकालय हो सकता है, या आपके स्वयं के प्रयासों द्वारा बनाई गई कोई चीज हो सकती है।

इंटरनेट पर इस तरह की परियोजनाओं की खोज करते हुए, मैं ट्विटर पर हाल ही में चर्चा के सूत्र में आया, जो अपेक्षाकृत नए पुस्तकालयों के बारे में बात करता था। मैंने वहां उल्लिखित कई पुस्तकालयों को देखा।

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


बटन घटक चक्र प्रलेखन


बटन अर्थ यूआई रिएक्ट प्रलेखन

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

फ़ाइलें

कल्पना करें, प्रदर्शन विश्लेषण के वर्णित तरीके को प्रदर्शित करने के लिए, कि अध्ययन के तहत पुस्तकालय में एक Button घटक है, जिसका कोड Button.js फ़ाइल में है। इकाई परीक्षण Button-test.js साथ फ़ाइल इस फ़ाइल Button-test.js जुड़ी है, साथ ही घटक का उपयोग करने के उदाहरण के साथ एक फ़ाइल है। Button-example.js हमें कुछ प्रकार के परीक्षण पृष्ठ बनाने की आवश्यकता है, जिसके वातावरण में परीक्षण कोड चलाया जा सकता है। test.html जैसा test.html ।

अंग

यहाँ एक साधारण Button घटक है। मैं यहां रिएक्ट का उपयोग करता हूं, लेकिन आपके घटकों को आपके लिए सुविधाजनक किसी भी तकनीक का उपयोग करके लिखा जा सकता है।

 import React from 'react'; const Button = (props) =>  props.href    ? <a {...props} className="Button"/>    : <button {...props} className="Button"/> export default Button; 

उदाहरण

और यहां Button घटक का उपयोग करने का एक उदाहरण है। जैसा कि आप देख सकते हैं, इस मामले में दो घटक विकल्प हैं जो विभिन्न गुणों का उपयोग करते हैं।

 import React from 'react'; import Button from 'Button'; export default [  <Button onClick={() => alert('ouch')}>    Click me  </Button>,  <Button href="https://reactjs.com">    Follow me  </Button>, ] 

कसौटी

यहाँ test.html पृष्ठ है जो किसी भी घटक को लोड कर सकता है। performance ऑब्जेक्ट के लिए विधि कॉल को नोटिस करें। यह उनकी मदद से है कि हम, हमारे अनुरोध पर, Chrome प्रदर्शन लॉग फ़ाइल में लिखें। बहुत जल्द हम इन रिकॉर्ड्स का इस्तेमाल करेंगे।

 const examples =  await import(location.hash + '-example.js'); examples.forEach(example =>  performance.mark('my mark start');  ReactDOM.render(<div>{example}</div>, where);  performance.mark('my mark end');  performance.measure(    'my mark', 'my mark start', 'my mark end'); ); 

टेस्ट रनर

Chrome में परीक्षण पृष्ठ लोड करने के लिए, हम Puppeteer Node.js लाइब्रेरी का उपयोग कर सकते हैं, जो हमें ब्राउज़र के प्रबंधन के लिए API तक पहुँच प्रदान करता है। आप किसी भी ऑपरेटिंग सिस्टम पर इस लाइब्रेरी का उपयोग कर सकते हैं। इसकी क्रोम की अपनी प्रति है, लेकिन इसका उपयोग डेवलपर के कंप्यूटर पर पहले से मौजूद विभिन्न संस्करणों के क्रोम या क्रोमियम की आवृत्ति के साथ काम करने के लिए भी किया जा सकता है। क्रोम को लॉन्च किया जा सकता है ताकि इसकी खिड़की अदृश्य हो। टेस्ट स्वचालित रूप से किए जाते हैं, जबकि डेवलपर को ब्राउज़र विंडो देखने की आवश्यकता नहीं होती है। क्रोम को सामान्य मोड में लॉन्च किया जा सकता है। यह डीबगिंग उद्देश्यों के लिए उपयोगी है।

यहाँ एक उदाहरण Node.js स्क्रिप्ट है जो कमांड लाइन से चलती है जो एक परीक्षण पृष्ठ को लोड करती है और डेटा को एक प्रदर्शन लॉग फ़ाइल में लिखती है। tracing.start() और end() कमांड के बीच ब्राउजर में होने वाली हर tracing.start() को trace.json फाइल में trace.json है।

 import pup from 'puppeteer'; const browser = await pup.launch(); const page = await browser.newPage(); await page.tracing.start({path: 'trace.json'}); await page.goto('test.html#Button'); await page.tracing.stop(); await browser.close(); 

डेवलपर ट्रेसिंग की "श्रेणियों" को निर्दिष्ट करके प्रदर्शन डेटा के "विस्तार" का प्रबंधन कर सकता है। यदि आप क्रोम में chrome://tracing पर जाते हैं तो आप उपलब्ध श्रेणियों की सूची देख सकते हैं chrome://tracing , Record क्लिक करें और दिखाई देने वाली विंडो में Edit categories को Edit categories अनुभाग खोलें।


प्रदर्शन लॉग में लिखे गए डेटा की संरचना को कॉन्फ़िगर करना

परिणाम

Puppeteer का उपयोग करके परीक्षण पृष्ठ की जांच करने के बाद, आप chrome://tracing में ब्राउज़र पर जाकर प्रदर्शन माप के परिणामों का विश्लेषण कर सकते हैं chrome://tracing और बस रिकॉर्ड किए गए trace.json फ़ाइल को डाउनलोड करना।


ट्रेस.जॉन विज़ुअलाइज़ेशन

यहां आप performance.measure('my mark') पर कॉल करने के परिणाम देख सकते हैं performance.measure('my mark') विधि। measure() कॉल केवल डीबगिंग उद्देश्यों के लिए है, यदि डेवलपर trace.json फ़ाइल को खोलना और देखना चाहता है। पृष्ठ के साथ जो कुछ भी हुआ वह ब्लॉक my mark में संलग्न है।

यहाँ एक trace.json है। trace.json :


ट्रेस .json फ़ाइल का टुकड़ा

यह पता लगाने के लिए कि हमें क्या चाहिए, यह End मार्कर के एक ही संकेतक से Start मार्कर के प्रोसेसर निर्देशों ( ticount ) की संख्या के संकेतक को घटाने के लिए पर्याप्त है। यह आपको यह पता लगाने की अनुमति देता है कि ब्राउज़र में घटक को प्रदर्शित करने के लिए कितने प्रोसेसर निर्देशों की आवश्यकता है। यह वही संख्या है जिसका उपयोग आप यह पता लगाने के लिए कर सकते हैं कि क्या कोई घटक तेज़ या धीमा हो गया है।

शैतान विवरण में है

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

कचरा संग्रह से संबंधित डेटा ब्लॉक (यह "डेटा ब्लॉक" अधिक सही ढंग से "ईवेंट" कहलाता है) को V8.GCScavenger कहा जाता है। इसके tidelta को प्रोसेसर निर्देश की संख्या से घटाया जाना चाहिए जो घटक को प्रस्तुत करता है। यहाँ ट्रेस घटनाओं के लिए प्रलेखन है। सच है, यह पुराना है, और इसमें उन संकेतकों की जानकारी नहीं है जिनकी हमें आवश्यकता है:

• tidelta - एक घटना को संसाधित करने के लिए आवश्यक प्रोसेसर निर्देशों की संख्या।
• ticount - घटना शुरू करने के लिए निर्देशों की संख्या।

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


एक ही घटक के 10 प्रतिपादन संचालन

यहां एक और विवरण दिया गया है: यदि घटक कुछ अतुल्यकालिक संचालन करता है (उदाहरण के लिए, यह setTimeout() या fetch() ) का उपयोग करता है, तो अतुल्यकालिक कोड द्वारा बनाई गई प्रणाली पर लोड को ध्यान में नहीं रखा जाता है। शायद यह अच्छा है। शायद यह बुरा है। यदि आप ऐसे घटकों के प्रदर्शन की जांच कर रहे हैं, तो अतुल्यकालिक कोड के एक अलग अध्ययन पर विचार करें।

मजबूत संकेत

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


स्थिर माप परिणाम

नीचे का ग्राफ रिएक्ट में एक सरल <span> तत्व के 10 रेंडर संचालन के माप परिणामों को दर्शाता है। इन परिणामों में और कुछ भी शामिल नहीं है। यह पता चला है कि इस ऑपरेशन के लिए 2.15 से 2.2 मिलियन प्रोसेसर निर्देशों की आवश्यकता है। यदि आप <p> में <span> लपेटते हैं, तो ऐसे डिज़ाइन को आउटपुट करने के लिए आपको लगभग 2.3 मिलियन निर्देशों की आवश्यकता होती है। सटीकता का यह स्तर मुझे चौंकाता है। यदि कोई डेवलपर एक <p> एक <p> तत्व को जोड़ने पर दिखाई देने वाले प्रदर्शन अंतर को देख सकता है, तो इसका मतलब है कि डेवलपर के हाथों में एक बहुत शक्तिशाली उपकरण है।

इस तरह की सटीकता के माप का प्रतिनिधित्व करने के लिए वास्तव में डेवलपर पर निर्भर है। यदि उसे इस तरह की सटीकता की आवश्यकता नहीं है, तो वह हमेशा बड़े टुकड़ों के प्रतिपादन प्रदर्शन को माप सकता है।

अतिरिक्त प्रदर्शन की जानकारी

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

परिणाम

क्या आज हर किसी के लिए यह संभव है कि इसका उपयोग आज यहां किया जाए? हाँ आप कर सकते हैं। ऐसा करने के लिए, आपको क्रोम संस्करण 78 या उच्चतर की आवश्यकता है। यदि trace.json में ticount और tidelta , तो उपरोक्त आपके लिए उपलब्ध है। Chrome के पहले के संस्करण नहीं हैं।

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

यह ध्यान दिया जाना चाहिए कि प्रोसेसर निर्देशों पर जानकारी प्रदान करने में सक्षम होने के लिए ब्राउज़र के लिए, आपको कुछ झंडे का उपयोग करने की आवश्यकता होगी - ये हैं- कोई --no-sandbox और --enable-thread-instruction-count । यहाँ कैसे उन्हें Puppeteer द्वारा शुरू किए गए ब्राउज़र में पास किया जाए:

 await puppeteer.launch({  args: [    '--no-sandbox',    '--enable-thread-instruction-count',  ]}); ', await puppeteer.launch({  args: [    '--no-sandbox',    '--enable-thread-instruction-count',  ]}); 

उम्मीद है कि अब आप अपने वेब एप्लिकेशन प्रदर्शन विश्लेषण को अगले स्तर पर ले जा सकते हैं।

प्रिय पाठकों! क्या आप यहां प्रस्तुत वेब परियोजनाओं के प्रदर्शन के विश्लेषण के लिए पद्धति का उपयोग करने की योजना बना रहे हैं?