🌵 🚩 🤜🏻 वेब पर टर्मिनल आउटपुट का प्रदर्शन और अनुकूलन 👵 👰🏾 💝

बहुत पहले नहीं, मैं एक सरल और एक ही समय में दिलचस्प काम में आया था: एक वेब अनुप्रयोग में केवल-पढ़ने के लिए टर्मिनल लागू करना। कार्य में रुचि तीन महत्वपूर्ण पहलुओं द्वारा दी गई थी:

बुनियादी एएनएसआई से बचने के क्रम के लिए समर्थन
कम से कम 50,000 डेटा लाइनों के लिए समर्थन
उपलब्ध होते ही डेटा प्रदर्शित करें।

इस लेख में मैं इस बारे में बात करूंगा कि इसे किस तरह लागू किया गया और फिर कैसे इसे सभी ने अनुकूलित किया।

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

यह क्यों था?

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

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

लेकिन पहले, सर्वर प्रसंस्करण और स्वरूपण के लिए जिम्मेदार था। और मैं इसे बड़ी संख्या में कारणों से सुधारना चाहता था:

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

इसलिए, वेब अनुप्रयोग के लिए पूरे पार्सिंग तर्क को स्थानांतरित करने का निर्णय लिया गया, और सर्वर पर केवल कच्चे डेटा को स्ट्रीमिंग करना छोड़ दिया गया

समस्या का बयान

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

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

इसके अलावा, पाठ के बीच URL हो सकते हैं जिन्हें पहचानने और हाइलाइट करने की भी आवश्यकता होती है।

हम तैयार पुस्तकालय और ...

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

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

टर्मिनल को जोड़ने की कोशिश करने में मुझे दोपहर 2 बजे का समय लगा और मैं इसका सामना नहीं कर सका । निश्चित रूप से।
अलग लाइन हाइट्स, टेढ़ा चयन, टर्मिनल का अनुकूल आकार, एक बहुत ही अजीब एपीआई, सेंस डॉक्यूमेंटेशन की कमी ...

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

अंतिम एल्गोरिथ्म का विवरण

सबसे पहले, मैंने अजगर में लागू वर्तमान एल्गोरिथ्म की नकल की और इसे जावास्क्रिप्ट के लिए अनुकूलित किया (बस घुंघराले ब्रेसिज़ को हटा दिया और सिंटैक्स के लिए एक और)।

मैं पुराने एल्गोरिथ्म के सभी मुख्य पेशेवरों और विपक्षों को जानता था, इसलिए मुझे केवल इसमें अप्रभावी स्थानों को सुधारने की आवश्यकता थी।

विचार-विमर्श, परीक्षण और त्रुटि के बाद, मैं निम्नलिखित विकल्प पर बस गया: हम एल्गोरिथ्म को 2 घटकों में विभाजित करते हैं:

पाठ पार्स करने और "टर्मिनल" की वर्तमान स्थिति को संग्रहीत करने के लिए मॉडल
मानचित्रण जो HTML में मॉडल का अनुवाद करता है

मॉडल (संरचना और एल्गोरिथ्म)

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

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

प्रदर्शन

HTML तत्वों के रूप में पाठ प्रदर्शित करता है
यदि स्ट्रिंग बदल गई है, तो स्ट्रिंग के सभी तत्वों को पूरी तरह से बदल देता है
शैलियों के आधार पर प्रत्येक पंक्ति को तोड़ता है: प्रत्येक शैलीगत खंड का अपना तत्व होता है

इस तरह की संरचना के साथ, परीक्षण एक काफी सरल कार्य है - हम पाठ को मॉडल में (एक पैकेज में या कुछ हिस्सों में) स्थानांतरित करते हैं और इसमें सभी लाइनों और शैलियों की वर्तमान स्थिति की जांच करते हैं। और सिर्फ कुछ परीक्षणों को प्रदर्शित करने के लिए, क्योंकि यह हमेशा बदली हुई रेखाओं को फिर से बनाता है।

एक महत्वपूर्ण लाभ प्रदर्शन का एक निश्चित आलस्य भी है। यदि पाठ के एक टुकड़े में हम एक ही लाइन (उदाहरण के लिए, प्रगति बार) को ओवरराइट करते हैं, तो मॉडल के काम करने के बाद, प्रदर्शन के लिए यह एक परिवर्तित रेखा की तरह दिखेगा।

डोम बनाम कैनवस

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

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

अंत में, मेरा लक्ष्य 50k लाइनों का था, और मुझे पता था कि पुराने एल्गोरिथ्म के काम के आधार पर DOM को इससे निपटना था।

अनुकूलन

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

प्रोफाइलिंग को 10k लाइनों पर किया गया था, जिनमें से प्रत्येक में स्टाइलिश तत्व थे। DOM तत्वों की कुल संख्या लगभग 100k है।

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

नीचे मैं सबसे दिलचस्प सुधारों पर अधिक विस्तार से ध्यान देना चाहूंगा। और शुरुआत के लिए, क्या था का एक ग्राफ:

मेमोरी से कोड को हटाने के द्वारा सभी प्रोफाइलिंग ग्राफिक्स को कार्यान्वयन के बाद बनाया गया था।

string.trim

सबसे पहले, मैं समझ से बाहर था। यह एक बहुत ही महत्वपूर्ण मात्रा में सीपीयू (यह मुझे लगता है कि यह लगभग 10-20% था) खा गया।

ट्रिम () भाषा का मूल कार्य है। यह किसी प्रकार के पुस्तकालय का उपयोग क्यों कर रहा है? और यहां तक कि अगर यह किसी तरह का पॉलीफ़िल है, तो यह क्रोम के नवीनतम संस्करण पर क्यों चालू हुआ?

थोड़ी गुगली और जवाब मिला: https://babeljs.io/docs/en/babel-preset-env । डिफ़ॉल्ट रूप से, यह पॉलीफ़िल को काफी बड़ी संख्या में ब्राउज़रों के लिए सक्षम बनाता है, और संकलन चरण में ऐसा करता है। मेरे लिए समाधान 'targets': '> 0.25%, not dead' निर्दिष्ट करना था 'targets': '> 0.25%, not dead'
लेकिन अंत में, मैंने ट्रिम कॉल को पूरी तरह से हटा दिया, अनावश्यक के रूप में।

Vue.js

पिछले वर्ष, मैंने टर्मिनल घटक को Vue.js. अब मुझे इसे वापस वेनिला में स्थानांतरित करना था, इसका कारण नीचे स्क्रीनशॉट में है (देखें Vue.js से जुड़ी लाइनों की संख्या):

मैंने Vue घटक में केवल आवरण, शैलियों और माउस प्रसंस्करण को छोड़ दिया। DOM एलिमेंट्स बनाने से जुड़ी हर चीज़ शुद्ध JS में चली गई, जो कि Vue घटक से एक सामान्य फ़ील्ड (जो कि फ्रेमवर्क द्वारा निगरानी नहीं की जाती है) से जुड़ी हुई है।

 created() { this.terminalModel = new TerminalModel(); this.terminal = new Terminal(this.terminalModel); },

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

नए आइटम जोड़ना

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

समस्या को हल करने के लिए, एक DocumentFragment है। सबसे पहले, हम सभी तत्वों को इसमें जोड़ते हैं, और फिर हम इसे मूल घटक में जोड़ते हैं। ब्राउज़र आने वाले घटकों की इनलाइन का ख्याल रखेगा।

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

स्पान बनाम डिव

वास्तव में, इसे display:inline (स्पैन) बनाम display:block (डिव) कहा जा सकता है।

शुरू में, मेरे पास स्पैन में हर लाइन थी और एक लाइन ब्रेक चरित्र के साथ समाप्त हुई। हालांकि, प्रदर्शन के मामले में, यह बहुत प्रभावी नहीं है: ब्राउज़र को यह पता लगाना होगा कि तत्व कहाँ शुरू होता है और समाप्त होता है। प्रदर्शन के साथ: ब्लॉक, ऐसी गणना बहुत सरल है।

लगभग 2 बार एक दिव्य त्वरित प्रतिपादन के साथ प्रतिस्थापित।

दुर्भाग्य से, display:block के मामले में display:block पाठ की कई पंक्तियों को उजागर करना बदतर दिखता है:

लंबे समय तक मैं यह तय नहीं कर सका कि कौन सा बेहतर है - अतिरिक्त 2 सेकंड का प्रतिपादन या मानव चयन। परिणामस्वरूप, व्यावहारिकता ने सुंदरता को हरा दिया।

स्तर 10 सीएसएस जादूगर

रेंडरिंग समय का एक और ~ 10% सीएसएस "अनुकूलन" द्वारा काट दिया गया था, जिसका उपयोग मैं पाठ को प्रारूपित करने के लिए करता हूं।

वेब विकास में अनुभवहीनता और मेरे खिलाफ निभाई गई बुनियादी बातों की समझ। मैंने सोचा था कि चयनकर्ता जितना सटीक होंगे, बेहतर होगा, लेकिन विशेष रूप से मेरे मामले में, ऐसा नहीं था।

टर्मिनल में पाठ को प्रारूपित करने के लिए, मैंने निम्नलिखित चयनकर्ताओं का उपयोग किया:

 #script-panel-container .log-content > div > span.text_color_green,

लेकिन (क्रोम में), निम्नलिखित विकल्प थोड़ा तेज है:

 span.text_color_green

मैं वास्तव में इस चयनकर्ता को पसंद नहीं करता, क्योंकि बहुत वैश्विक है, लेकिन प्रदर्शन अधिक महंगा है।

string.split

यदि आपके पास पिछले बिंदुओं में से एक के कारण एक डीजा वु है, तो यह गलत है। इस बार यह पॉलीफ़िल के बारे में नहीं है, लेकिन क्रोम में मानक कार्यान्वयन के बारे में है:

(मैंने string.split को defSplit में लपेटा ताकि फ़ंक्शन प्रोफाइलर में दिखाई दे)

1% trifles हैं। लेकिन मुझमें आदर्शवादी साइकिल चालक प्रेतवाधित था। मेरे मामले में, विभाजन को हमेशा एक समय में और बिना किसी नियमित रूप से किया जाता है। इसलिए, मैंने एक सरल विकल्प लागू किया। यहाँ परिणाम है:

fastSplit

 function fastSplit(str, separatorChar) { if (str === '') { return ['']; } let result = []; let lastIndex = 0; for (let i = 0; i < str.length; i++) { const char = str[i]; if (char === separatorChar) { const chunk = str.substr(lastIndex, i - lastIndex); lastIndex = i + 1; result.push(chunk); } } if (lastIndex < str.length) { const lastChunk = str.substr(lastIndex, str.length - lastIndex); result.push(lastChunk); } return result; }

मेरा मानना है कि इसके बाद, वे मुझे बिना साक्षात्कार के Google Chrome टीम में ले जाने के लिए बाध्य हैं।

अनुकूलन, बाद

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

मेरे मामले के लिए, मैंने मुख्य उपयोग के मामले को चुना और इसके संचालन समय को 15 सेकंड से 5 सेकंड तक अनुकूलित किया। इस पर मैंने रुकने का फैसला किया।

अभी भी कुछ स्थानों पर मैं सुधार करने की योजना बना रहा हूं, लेकिन यह प्राप्त अनुभव के लिए धन्यवाद है।

बोनस। उत्परिवर्तन परीक्षण।

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

चूंकि तकनीक और पुस्तकालय दोनों मेरे लिए नए हैं, इसलिए मैंने थोड़ा रक्त से प्राप्त करने का फैसला किया: केवल एक घटक का परीक्षण करने के लिए - मॉडल। इस मामले में, आप स्पष्ट रूप से इंगित कर सकते हैं कि हम किस फ़ाइल का परीक्षण कर रहे हैं, और कौन सा परीक्षण सूट इसके लिए अभिप्रेत है।

लेकिन जो भी कह सकता है, मुझे कर्म और वेबपैक के साथ एकीकरण हासिल करने के लिए बहुत कुछ करना था।

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

उसके बाद, आलस्य की जीत हुई, और इस समय परिणाम निम्नानुसार हैं (128 परीक्षणों के लिए):

 Ran 79.04 tests per mutant on average. ------------------|---------|----------|-----------|------------|---------| File | % score | # killed | # timeout | # survived | # error | ------------------|---------|----------|-----------|------------|---------| terminal_model.js | 73.10 | 312 | 25 | 124 | 1 | ------------------|---------|----------|-----------|------------|---------| 23:01:08 (18212) INFO Stryker Done in 26 minutes 32 seconds.

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

और सबसे महत्वपूर्ण बात, इस दृष्टिकोण ने मुझे फिर से 100% कवरेज के बारे में सोचा और क्या यह परीक्षण के साथ सब कुछ कवर करने के लायक है: अब इस प्रश्न का उत्तर देते समय मेरी राय "हाँ" के करीब है।

निष्कर्ष

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

और हमेशा की तरह, "पहली रूपरेखा, फिर अनुकूलन" दृष्टिकोण अंतर्ज्ञान से बहुत बेहतर काम करता है।

संदर्भ

पुराना कार्यान्वयन:

नया कार्यान्वयन:

दुर्भाग्य से, कोई वेब घटक डेमो नहीं है, इसलिए आप इसे प्रहार करने में सक्षम नहीं होंगे। इसलिए मैं पहले से माफी मांगता हूं

आपके समय के लिए धन्यवाद, मुझे टिप्पणियों, सुझावों और उचित आलोचना पर खुशी होगी!

वेब पर टर्मिनल आउटपुट का प्रदर्शन और अनुकूलन