Xterm.js: बफर प्रदर्शन में सुधार

एक अन्य दृष्टिकोण जिसे इसमें मिलाया जा सकता है: डिस्क पर निष्क्रिय स्क्रॉलबैक प्रविष्टियों को बाहर करने के लिए इंडेक्सडब, वेबएसक्यूएल या फाइल सिस्टम एपीआई का उपयोग करें।

बढ़िया प्रस्ताव। मैं इससे सहमत हूं । 3 अभी के लिए जाने का सबसे अच्छा तरीका है क्योंकि यह हमें असली रंग का समर्थन करते हुए स्मृति को बचाने की सुविधा देता है।

अगर हम वहां पहुंच जाते हैं और चीजें अच्छी तरह से चलती रहती हैं, तो हम 5 में प्रस्तावित या उस समय हमारे दिमाग में आने वाले किसी अन्य तरीके से अनुकूलित कर सकते हैं और समझ में आता है।

3. महान है .

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

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

भविष्य में वेबवर्कर के बारे में +100, लेकिन मुझे लगता है कि हमें उन ब्राउज़रों के सूची संस्करणों को बदलने की आवश्यकता है जिनका हम समर्थन कर रहे हैं क्योंकि उनमें से सभी इसका उपयोग नहीं कर सकते हैं ...

जब मैं Int32Array कहता हूं, तो यह एक नियमित सरणी होगी यदि यह पर्यावरण द्वारा समर्थित नहीं है।

@mofux भविष्य में WebWorker साथ अच्छी सोच

@AndrienkoAleksandr हाँ अगर हम WebWorker का उपयोग करना चाहते हैं तो हमें फीचर डिटेक्शन के माध्यम से विकल्प का समर्थन करने की आवश्यकता होगी।

वाह अच्छी सूची :)

मैं भी 3 की ओर झुकता हूं [start, end] सूची को नीचा दिखाएंगे) .

@AndrienkoAlexandr हाँ मुझे वेबवर्कर विचार भी पसंद है क्योंकि यह मेनथ्रेड से _some_ बोझ उठा सकता है। यहां समस्या है (इस तथ्य के अलावा कि यह सभी वांछित लक्ष्य प्रणालियों द्वारा समर्थित नहीं हो सकता है) _some_ है - जेएस भाग अब सभी अनुकूलन के साथ इतना बड़ा सौदा नहीं है, xterm.js ने समय के साथ देखा है। वास्तविक समस्या प्रदर्शन-वार ब्राउज़र की लेआउटिंग/रेंडरिंग है ...

@mofux कुछ "विदेशी स्मृति" के लिए पेजिंग चीज़ एक अच्छा विचार है, हालांकि यह कुछ उच्च अमूर्तता का हिस्सा होना चाहिए, न कि "जिम्मे एक इंटरैक्टिव टर्मिनल विजेट चीज़" जो xterm.js है। यह एक एडन इम्हो द्वारा हासिल किया जा सकता है।

ऑफटॉपिक: क्या सरणियों के साथ कुछ परीक्षण किए गए बनाम टाइप किए गए सरणी बनाम asm.js। मैं केवल इतना कह सकता हूं - ओएमजी, यह साधारण चर भार और सेट (एफएफ पर और भी अधिक) के लिए 1 : 1,5 : 10 जैसा है। यदि शुद्ध जेएस गति वास्तव में चोट पहुंचाने लगती है, तो बचाव के लिए "asm का उपयोग करें" हो सकता है। लेकिन मैं इसे अंतिम उपाय के रूप में देखूंगा क्योंकि इसका मतलब मूलभूत परिवर्तन होगा। और webassembly अभी तक जहाज के लिए तैयार नहीं है।

ऑफटॉपिक: क्या सरणियों के साथ कुछ परीक्षण किए गए बनाम टाइप किए गए सरणी बनाम asm.js। मैं केवल इतना कह सकता हूं - ओएमजी, यह साधारण चर भार और सेट के लिए 1: 1,5: 10 जैसा है (एफएफ पर और भी अधिक)

@jerch स्पष्ट करने के लिए, क्या सरणियाँ बनाम typedarrays 1:1 से 1:5 है?

अल्पविराम के साथ अच्छा पकड़ - मेरा मतलब गति के अनुसार 10:15:100 । लेकिन केवल एफएफ टाइप किए गए सरणी सामान्य सरणी से थोड़ा तेज थे। asm सभी ब्राउज़रों पर js सरणियों की तुलना में कम से कम 10 गुना तेज है - FF, वेबकिट (सफारी), ब्लिंक/V8 (क्रोम, ओपेरा) के साथ परीक्षण किया गया।

@jerch कूल, बेहतर मेमोरी के अलावा टाइपएरे से 50% की गति निश्चित रूप से अभी के लिए निवेश करने लायक होगी।

स्मृति बचत के लिए विचार - शायद हम प्रत्येक वर्ण के लिए width छुटकारा पा सकें। एक कम खर्चीला wcwidth संस्करण लागू करने का प्रयास करेंगे।

@jerch हमें इसे काफी एक्सेस करने की आवश्यकता है, और हम इसे या कुछ भी आलसी लोड नहीं कर सकते हैं क्योंकि जब रिफ्लो आता है तो हमें बफर में प्रत्येक वर्ण की चौड़ाई की आवश्यकता होगी। भले ही यह तेज़ था, फिर भी हम इसे इधर-उधर रखना चाह सकते हैं।

इसे वैकल्पिक बनाने के लिए बेहतर हो सकता है, यदि यह निर्दिष्ट नहीं है तो 1 मान लें:

type CharData = [string, number?]; // not sure if this is valid syntax

[
  // 'a'
  ['a'],
  // '文'
  ['文', 2],
  // after wide
  ['', 0],
  ...
]

@ टायरियर हाँ - ठीक है क्योंकि मैंने इसे पहले ही लिखा है, कृपया इसे पीआर # 798 में देखें
लुकअप टेबल के लिए 16k बाइट्स की लागत के लिए मेरे कंप्यूटर पर स्पीडअप 10 से 15 गुना है। हो सकता है कि अगर अभी भी जरूरत हो तो दोनों का संयोजन संभव है।

भविष्य में हम कुछ और झंडे का समर्थन करेंगे: https://github.com/sourcelair/xterm.js/issues/580

एक और विचार: टर्मिनल का केवल निचला भाग ( Terminal.ybase से Terminal.ybase + Terminal.rows ) गतिशील है। स्क्रॉलबैक जो अधिकांश डेटा बनाता है वह पूरी तरह से स्थिर है, शायद हम इसका लाभ उठा सकते हैं। मुझे यह हाल तक नहीं पता था, लेकिन यहां तक ​​​​कि डिलीट लाइन्स (DL, CSI Ps M) जैसी चीजें भी स्क्रॉलबैक को वापस नीचे नहीं लाती हैं, बल्कि दूसरी लाइन डालें। इसी तरह, ऊपर स्क्रॉल करें (SU, CSI Ps S) आइटम को Terminal.scrollTop पर हटाता है और Terminal.scrollBottom पर एक आइटम सम्मिलित करता है।

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

एक और विचार: CharAttributeEntry को पंक्तियों तक सीमित रखना शायद एक बेहतर विचार है क्योंकि अधिकांश एप्लिकेशन इस तरह काम करते हैं। इसके अलावा अगर टर्मिनल का आकार बदला जाता है तो "रिक्त" पैडिंग को दाईं ओर जोड़ा जाता है जो समान शैलियों को साझा नहीं करता है।

उदाहरण:

लाल/हरे रंग के अंतर के दाईं ओर अस्थिर "रिक्त" कक्ष हैं।

@ टायरियर
इस मुद्दे को एजेंडे पर वापस लाने का कोई मौका? कम से कम आउटपुट गहन कार्यक्रमों के लिए टर्मिनल डेटा रखने का एक अलग तरीका बहुत मेमोरी और समय बचा सकता है। यदि हम इनपुट स्ट्रिंग के एकल वर्णों को विभाजित करने और सहेजने से बच सकते हैं, तो 2/3/4 के कुछ हाइब्रिड एक विशाल थ्रूपुट को बढ़ावा देंगे। साथ ही विशेषताओं को केवल एक बार बदलने के बाद सहेजना स्मृति को बचाने में मदद करेगा।

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

@jerch मैं कुछ हफ़्ते में प्राग में एक दिन मिलूंगा और हम कुछ आंतरिक सुधार करने/शुरू करने जा रहे थे कि कैसे टेक्स्ट विशेषताओं को संभाला जाता है जो इसे कवर करता है

https://github.com/xtermjs/xterm.js/pull/1460#issuecomment -390500944 से

अहंकार थोडा महंगा है क्योंकि प्रत्येक चार को दो बार मूल्यांकन करने की आवश्यकता होती है

@jerch यदि आपके पास बफर से टेक्स्ट की तेज़ पहुंच के बारे में कोई विचार है, तो हमें बताएं। वर्तमान में इसमें से अधिकांश केवल एक ही वर्ण है जैसा कि आप जानते हैं, लेकिन यह एक ArrayBuffer , एक स्ट्रिंग, आदि हो सकता है। मैं सोच रहा हूं कि हमें स्क्रॉलबैक के किसी भी तरह अपरिवर्तनीय होने का अधिक लाभ लेने के बारे में सोचना चाहिए।

वैसे मैंने अतीत में ArrayBuffers के साथ बहुत प्रयोग किया है:

• वे विशिष्ट तरीकों के लिए रनटाइम के संबंध में Array से थोड़े खराब हैं (शायद इंजन विक्रेताओं द्वारा अभी भी कम अनुकूलित)
• new UintXXArray [] साथ शाब्दिक सरणी निर्माण से कहीं अधिक खराब है
• वे कई बार भुगतान करते हैं यदि आप डेटा संरचना (10 गुना तक) को प्रीलोक और पुन: उपयोग कर सकते हैं, यह वह जगह है जहां मिश्रित सरणी की लिंक्ड सूची प्रकृति दृश्यों के पीछे भारी आवंटन और जीसी के कारण प्रदर्शन को खाती है
• स्ट्रिंग डेटा के लिए आगे और पीछे रूपांतरण सभी लाभ खाता है - एक दया जेएस Uint16Array कन्वर्टर्स को मूल स्ट्रिंग प्रदान नहीं करता है (हालांकि TextEncoder साथ आंशिक रूप से करने योग्य)

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

TL;DR ArrayBuffer बेहतर है यदि आप डेटा संरचना का प्रचार और पुन: उपयोग कर सकते हैं। बाकी सब चीजों के लिए सामान्य सरणियाँ बेहतर हैं। स्ट्रिंग्स को ArrayBuffers में निचोड़ने लायक नहीं है।

एक नया विचार जिसके साथ मैं आया था, जितना संभव हो सके स्ट्रिंग निर्माण को कम करने की कोशिश करता है, esp। बुरा विभाजन और जुड़ने से बचने की कोशिश करता है। यह नई InputHandler.print विधि, wcwidth और लाइन स्टॉप के साथ उपरोक्त आपके दूसरे विचार पर आधारित है:

• print अब कई टर्मिनल लाइनों तक पूरे तार प्राप्त करता है
• उन स्ट्रिंग्स को बिना किसी परिवर्तन के एक साधारण पॉइंटर सूची में सहेजें (कोई स्ट्रिंग आवंटन या जीसी नहीं, सूची आवंटन से बचा जा सकता है यदि एक prealloc'd संरचना के साथ प्रयोग किया जाता है) वर्तमान विशेषताओं के साथ
• अग्रिम कर्सर wcwidth(string) % cols
• विशेष मामला \n (हार्ड लाइन ब्रेक): कर्सर को एक लाइन से आगे बढ़ाएं, पॉइंटर सूची में स्थिति को हार्ड ब्रेक के रूप में चिह्नित करें
• रैपअराउंड के साथ विशेष केस लाइन ओवरफ्लो: स्ट्रिंग में सॉफ्ट लाइन ब्रेक के रूप में स्थिति को चिह्नित करें
• विशेष मामला \r : अधिलेखित होने के लिए अंतिम पंक्ति सामग्री (वर्तमान कर्सर स्थिति से अंतिम पंक्ति विराम तक) को कुछ पंक्ति बफर में लोड करें
• डेटा ऊपर की तरह प्रवाहित होता है, \r मामले के बावजूद कोई सेल एब्स्ट्रैक्शन और न ही स्ट्रिंग विभाजन की आवश्यकता है
• विशेषता परिवर्तन कोई समस्या नहीं है, जब तक कोई भी वास्तविक cols x rows प्रतिनिधित्व का अनुरोध नहीं करता है (वे केवल एटीआर ध्वज को बदलते हैं जो पूरे स्ट्रिंग के साथ सहेजा जाता है)

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

अब खतरनाक भाग 1 - कोई व्यक्ति कर्सर को cols x rows भीतर ले जाना चाहता है:

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

अब खतरनाक भाग 2 - रेंडरर कुछ आकर्षित करना चाहता है:

• थोड़े रेंडरर पर निर्भर करता है अगर हमें सेल मॉडल में ड्रिलडाउन करने की आवश्यकता है या लाइन ब्रेक और टेक्स्ट एट्र्स के साथ स्ट्रिंग ऑफ़सेट प्रदान कर सकते हैं

पेशेवरों:

• बहुत तेज़ डेटा प्रवाह
• सबसे आम InputHandler पद्धति के लिए अनुकूलित - print
• टर्मिनल आकार बदलने पर रीफ्लोइंग लाइनें संभव बनाता है

दोष:

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

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

@jerch

स्ट्रिंग्स को ArrayBuffers में निचोड़ने लायक नहीं है।

मुझे लगता है कि मोनाको अपने बफर को ArrayBuffer s में संग्रहीत करता है और यह काफी उच्च प्रदर्शन है। मैंने अभी तक कार्यान्वयन में बहुत गहराई से नहीं देखा है।

विशेष बुरा विभाजन और जुड़ने से बचने की कोशिश करता है

जो लोग?

मैं सोच रहा हूं कि हमें स्क्रॉलबैक के किसी भी तरह अपरिवर्तनीय होने का अधिक लाभ लेने के बारे में सोचना चाहिए।

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

@Tyriar स्क्रॉलबैक के बारे में - हाँ चूंकि यह कर्सर द्वारा कभी भी उपलब्ध नहीं है, यह स्क्रॉल आउट लाइनों के लिए सेल एब्स्ट्रैक्शन को छोड़ने के लिए कुछ मेमोरी को सहेज सकता है।

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

विशेष बुरा विभाजन और जुड़ने से बचने की कोशिश करता है

जो लोग?

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

@jerch अच्छी तरह से अगर व्यूपोर्ट का विस्तार किया जाता है, तो मुझे लगता है कि जब कोई लाइन हटा दी जाती है तो हम स्क्रॉलबैक भी खींच सकते हैं? उस पर 100% निश्चित नहीं है या भले ही यह सही व्यवहार हो।

@ टायरियर आह ठीक है। उत्तरार्द्ध के बारे में निश्चित नहीं है, मुझे लगता है कि देशी xterm इसे केवल वास्तविक माउस या स्क्रॉलबार स्क्रॉलिंग के लिए अनुमति देता है। यहां तक ​​​​कि एसडी/एसयू स्क्रॉलबफर सामग्री को "सक्रिय" टर्मिनल व्यूपोर्ट में वापस नहीं ले जाता है।

क्या आप मुझे मोनाको संपादक के स्रोत के बारे में बता सकते हैं, जहां ArrayBuffer का उपयोग किया जाता है? ऐसा लगता है कि मैं इसे स्वयं नहीं ढूंढ सकता: ब्लश:

हम्म बस TextEncoder/Decoder spec को फिर से पढ़ें, ArrayBuffers के साथ नोड-पीटीआई से फ्रंटएंड तक हम मूल रूप से utf-8 के साथ फंस गए हैं, जब तक कि हम इसे किसी बिंदु पर कठिन तरीके से अनुवाद नहीं करते हैं। xterm.js utf-8 को जागरूक बनाना? Idk, इसमें उच्च यूनिकोड वर्णों के लिए कई मध्यवर्ती कोडपॉइंट गणना शामिल होगी। प्रोसाइड - यह एएससीआई वर्णों के लिए स्मृति को बचाएगा।

@rebornix क्या आप हमें कुछ संकेत दे सकते हैं जहां मोनाको बफर स्टोर करता है?

टाइप किए गए सरणियों और नए पार्सर के लिए यहां कुछ संख्याएं दी गई हैं (अपनाना आसान था):

• UTF-8 (Uint8Array): print कार्रवाई 190 MB/s से 290 MB/s तक बढ़ जाती है
• UTF-16 (Uint16Array): print कार्रवाई 190 MB/s से 320 MB/s तक बढ़ जाती है

कुल मिलाकर यूटीएफ -16 काफी बेहतर प्रदर्शन करता है, लेकिन इसकी उम्मीद थी क्योंकि इसके लिए पार्सर अनुकूलित किया गया था। UTF-8 मध्यवर्ती कोडपॉइंट गणना से ग्रस्त है।

टाइप किए गए सरणी रूपांतरण के लिए स्ट्रिंग मेरे बेंचमार्क ls -lR /usr/lib ~ 4% जेएस रनटाइम खाती है (हमेशा 100 एमएस से नीचे, InputHandler.parse में लूप के माध्यम से किया जाता है)। मैंने रिवर्स रूपांतरण का परीक्षण नहीं किया (यह सेल स्तर द्वारा सेल पर InputHandller.print में निहित रूप से एटीएम किया जाता है)। समग्र रनटाइम स्ट्रिंग्स की तुलना में थोड़ा खराब है (पार्सर में सहेजा गया समय रूपांतरण समय की भरपाई नहीं करता है)। यह तब बदल सकता है जब अन्य भाग भी टाइप किए गए सरणी जागरूक हों।

और संबंधित स्क्रीनशॉट ( ls -lR /usr/lib साथ परीक्षण किया गया):

तार के साथ:

Uint16Array के साथ:

EscapeSequenceParser.parse लिए अंतर नोट करें, जो एक टाइप की गई सरणी (~30% तेज) से लाभ उठा सकता है। InputHandler.parse रूपांतरण करता है, इस प्रकार टाइप किए गए सरणी संस्करण के लिए यह बदतर है। इसके अलावा जीसी माइनर को टाइप किए गए सरणी के लिए और अधिक करना है (क्योंकि मैं सरणी को दूर फेंक देता हूं)।

संपादित करें: स्क्रीनशॉट में एक और पहलू देखा जा सकता है - जीसी ~ 20% रनटाइम के साथ प्रासंगिक हो जाता है, लंबे समय तक चलने वाले फ्रेम (लाल ध्वजांकित) सभी जीसी से संबंधित हैं।

बस एक और कुछ हद तक कट्टरपंथी विचार:

1. अपनी सरणीबफर आधारित वर्चुअल मेमोरी बनाएं, कुछ बड़ा (>5 एमबी)
   यदि सरणीबफ़र में int8 से int16 से int32 प्रकार के 4 पारदर्शी स्विच के गुणकों की लंबाई संभव है। आवंटक Uint8Array पर एक निःशुल्क अनुक्रमणिका देता है, इस सूचक को एक साधारण बिट शिफ्ट द्वारा Uint16Array या Uint32Array स्थिति में परिवर्तित किया जा सकता है।
2. मेमोरी में आने वाली स्ट्रिंग्स को UTF-16 के लिए uint16_t प्रकार के रूप में लिखें।
3. पार्सर स्ट्रिंग पॉइंटर्स पर चलता है और स्ट्रिंग स्लाइस के बजाय इस मेमोरी को पॉइंटर्स के साथ InputHandler में कॉल करता है।
4. वर्चुअल मेमोरी के अंदर टर्मिनल डेटा बफर को एक स्ट्रक्चर के रिंग बफर ऐरे के रूप में बनाएं जैसे कि देशी जेएस ऑब्जेक्ट्स के बजाय टाइप करें, शायद इस तरह (अभी भी सेल आधारित):

struct Cell {
    uint32_t *char_start;  // start pointer of cell content (JS with pointers hurray!)
    uint8_t length;        // length of content (8 bit here is sufficient)
    uint32_t attr;         // text attributes (might grow to hold true color someday)
    uint8_t width;         // wcwidth (maybe merge with other member, always < 4)
    .....                  // some other cell based stuff
}

पेशेवरों:

• जेएस वस्तुओं को छोड़ देता है और इस प्रकार जीसी जहां संभव हो (केवल कुछ स्थानीय वस्तुएं ही रहेंगी)
• वर्चुअल मेमोरी में केवल एक प्रारंभिक डेटा कॉपी की आवश्यकता है
• लगभग कोई malloc और free लागत (आवंटक/डीलोकेटर की चतुराई पर निर्भर करता है)
• बहुत सारी मेमोरी बचाएगा (जेएस ऑब्जेक्ट्स मेमोरी ओवरहेड से बचा जाता है)

दोष:

• कैवास्क्रिप्ट हॉरर शो में आपका स्वागत है: चीख:
• लागू करना कठिन है, थोड़े सब कुछ बदल देता है
• वास्तव में लागू होने तक गति लाभ स्पष्ट नहीं है

:मुस्कुराओ:

लागू करने में कठिन मज़ा, थोड़े सब कुछ बदल देता है

यह मोनाको के काम करने के तरीके के करीब है, मुझे यह ब्लॉग पोस्ट याद आया जिसमें चरित्र मेटाडेटा को संग्रहीत करने की रणनीति पर चर्चा की गई है https://code.visualstudio.com/blogs/2017/02/08/syntax-highlighting-optimizations

हाँ, मूल रूप से वही विचार है।

आशा है कि मेरा उत्तर जहां मोनाको बफर स्टोर करता है, बहुत देर नहीं हुई है।

एलेक्स और मैं ऐरे बफर के पक्ष में हैं और ज्यादातर समय यह हमें अच्छा प्रदर्शन देता है। कुछ जगहों पर हम ArrayBuffer का उपयोग करते हैं:

• टेक्स्ट बफ़र में लाइन ब्रेक ऑफ़सेट https://github.com/Microsoft/vscode/blob/rebornix/review/src/vs/editor/common/model/pieceTreeTextBuffer/pieceTreeBase.ts#L31 ।
• ऑफसेट <--> स्थिति मानचित्रण https://github.com/Microsoft/vscode/blob/rebornix/review/src/vs/editor/common/viewModel/prefixSumComputer.ts#L26
• टोकन https://github.com/Microsoft/vscode/blob/rebornix/review/src/vs/editor/common/model/textModelTokens.ts#L1 इसमें आपकी रुचि हो सकती है। हम स्रोत कोड को दूसरे थ्रेड में टोकन करते हैं और उन्हें ऐरे बफर में संग्रहीत करते हैं, और फिर हम उसी सरणी बफर का उपयोग व्यू मॉडल के बैकिंग स्टोर के रूप में करते हैं। मैं एक वेब कार्यकर्ता में टोकननाइज़र (नोड-ओनिगुरुमा) के साथ संचार करने के बारे में भी सोच रहा हूं और फिर यूआई कोड को प्रतिक्रिया के बारे में चिंता करने की आवश्यकता नहीं है और टोकन को मुख्य धागे में SharedArrayBuffer द्वारा साझा किया जा सकता है

हम ऐरे बफ़र के बजाय टेक्स्ट बफर के लिए सरल स्ट्रिंग्स का उपयोग करते हैं क्योंकि V8 स्ट्रिंग में हेरफेर करना आसान है

• हम फ़ाइल लोड करने की शुरुआत में एन्कोडिंग/डिकोडिंग करते हैं, इसलिए फ़ाइलें जेएस स्ट्रिंग में परिवर्तित हो जाती हैं। V8 यह तय करता है कि किसी कैरेक्टर को स्टोर करने के लिए एक बाइट या दो का उपयोग करना है या नहीं।
• हम टेक्स्ट बफ़र पर बहुत बार संपादन करते हैं, स्ट्रिंग्स को संभालना आसान होता है।
• हम नोडज देशी मॉड्यूल का उपयोग कर रहे हैं और जब आवश्यक हो तो वी 8 इंटर्नल तक पहुंच प्राप्त कर सकते हैं।

पिन किए गए @rebornix के लिंक ताकि कमिट्स जोड़े जाने पर वे

• https://github.com/Microsoft/vscode/blob/f1dcaaea48263a882017521f20c91149a516eca1/src/vs/editor/common/model/pieceTreeTextBuffer/pieceTreeBase.ts#L31
• https://github.com/Microsoft/vscode/blob/f1dcaaea48263a882017521f20c91149a516eca1/src/vs/editor/common/viewModel/prefixSumComputer.ts#L26
• https://github.com/Microsoft/vscode/blob/f1dcaaea48263a882017521f20c91149a516eca1/src/vs/editor/common/model/textModelTokens.ts#L1

निम्नलिखित सूची दिलचस्प अवधारणाओं का एक त्वरित सारांश है जिस पर मैंने ठोकर खाई है जो स्मृति उपयोग और/या रनटाइम को कम करने में मदद कर सकती है:

• FlatJS (https://github.com/lars-t-hansen/flatjs) - सरणी बफर आधारित ढेर के साथ कोडिंग में मदद करने के लिए मेटा भाषा
• http://2ality.com/2017/01/shared-array-buffer.html (ES2017 के हिस्से के रूप में घोषित, स्पेक्टर के कारण भविष्य अनिश्चित हो सकता है, वास्तविक संगामिति और वास्तविक परमाणु के साथ उस बहुत ही आशाजनक विचार के अलावा)
• webassembly/asm.js (वर्तमान स्थिति? अभी तक प्रयोग करने योग्य? कुछ समय के लिए इसके विकास का पालन नहीं किया है, हालांकि प्रभावशाली परिणामों के साथ एक गेम एआई के लिए सी लिब के साथ साल पहले एएसएम.जेएस के लिए एमस्क्रिप्टन का उपयोग किया गया था)
• https://github.com/AssemblyScript/assemblyscript

यहां संक्षेप में प्रस्तुत करने के लिए, यहां एक त्वरित हैक है कि हम टेक्स्ट विशेषताओं को "मर्ज" कैसे कर सकते हैं।

कोड मुख्य रूप से बफर डेटा के लिए मेमोरी को बचाने के विचार से प्रेरित होता है (रनटाइम को नुकसान होगा, अभी तक कितना परीक्षण नहीं किया गया है)। ईएसपी अग्रभूमि और पृष्ठभूमि के लिए आरजीबी के साथ टेक्स्ट विशेषताएँ (एक बार समर्थित) xterm.js को सेल लेआउट द्वारा वर्तमान सेल द्वारा बहुत सारी मेमोरी खा जाएगी। कोड विशेषताओं के लिए एक आकार बदलने योग्य रेफ-गिनती एटलस के उपयोग से इसे रोकने की कोशिश करता है। यह इम्हो एक विकल्प है क्योंकि एक टर्मिनल में शायद ही 1M से अधिक सेल होंगे, जो एटलस को 1M * entry_size बढ़ा देगा यदि सभी सेल अलग-अलग हों।

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

एटलस वर्तमान में केवल टेक्स्ट विशेषताओं को संबोधित करता है, लेकिन यदि आवश्यक हो तो सभी सेल विशेषताओं तक बढ़ाया जा सकता है। जबकि वर्तमान टर्मिनल बफर में विशेषता डेटा के लिए 2 32 बिट संख्याएं हैं (वर्तमान बफर डिज़ाइन में आरजीबी के साथ 4) एटलस इसे केवल एक 32 बिट संख्या तक कम कर देगा। एटलस प्रविष्टियों को और भी पैक किया जा सकता है।

interface TextAttributes {
    flags: number;
    foreground: number;
    background: number;
}

const enum AtlasEntry {
    FLAGS = 1,
    FOREGROUND = 2,
    BACKGROUND = 3
}

class TextAttributeAtlas {
    /** data storage */
    private data: Uint32Array;
    /** flag lookup tree, not happy with that yet */
    private flagTree: any = {};
    /** holds freed slots */
    private freedSlots: number[] = [];
    /** tracks biggest idx to shortcut new slot assignment */
    private biggestIdx: number = 0;
    constructor(size: number) {
        this.data = new Uint32Array(size * 4);
    }
    private setData(idx: number, attributes: TextAttributes): void {
        this.data[idx] = 0;
        this.data[idx + AtlasEntry.FLAGS] = attributes.flags;
        this.data[idx + AtlasEntry.FOREGROUND] = attributes.foreground;
        this.data[idx + AtlasEntry.BACKGROUND] = attributes.background;
        if (!this.flagTree[attributes.flags])
            this.flagTree[attributes.flags] = [];
        if (this.flagTree[attributes.flags].indexOf(idx) === -1)
            this.flagTree[attributes.flags].push(idx);
    }

    /**
     * convenient method to inspect attributes at slot `idx`.
     * For better performance atlas idx and AtlasEntry
     * should be used directly to avoid number conversions.
     * <strong i="10">@param</strong> {number} idx
     * <strong i="11">@return</strong> {TextAttributes}
     */
    getAttributes(idx: number): TextAttributes {
        return {
            flags: this.data[idx + AtlasEntry.FLAGS],
            foreground: this.data[idx + AtlasEntry.FOREGROUND],
            background: this.data[idx + AtlasEntry.BACKGROUND]
        };
    }

    /**
     * Returns a slot index in the atlas for the given text attributes.
     * To be called upon attributes changes, e.g. by SGR.
     * NOTE: The ref counter is set to 0 for a new slot index, thus
     * values will get overwritten if not referenced in between.
     * <strong i="12">@param</strong> {TextAttributes} attributes
     * <strong i="13">@return</strong> {number}
     */
    getSlot(attributes: TextAttributes): number {
        // find matching attributes slot
        const sameFlag = this.flagTree[attributes.flags];
        if (sameFlag) {
            for (let i = 0; i < sameFlag.length; ++i) {
                let idx = sameFlag[i];
                if (this.data[idx + AtlasEntry.FOREGROUND] === attributes.foreground
                    && this.data[idx + AtlasEntry.BACKGROUND] === attributes.background) {
                    return idx;
                }
            }
        }
        // try to insert into a previously freed slot
        const freed = this.freedSlots.pop();
        if (freed) {
            this.setData(freed, attributes);
            return freed;
        }
        // else assign new slot
        for (let i = this.biggestIdx; i < this.data.length; i += 4) {
            if (!this.data[i]) {
                this.setData(i, attributes);
                if (i > this.biggestIdx)
                    this.biggestIdx = i;
                return i;
            }
        }
        // could not find a valid slot --> resize storage
        const data = new Uint32Array(this.data.length * 2);
        for (let i = 0; i < this.data.length; ++i)
            data[i] = this.data[i];
        const idx = this.data.length;
        this.data = data;
        this.setData(idx, attributes);
        return idx;
    }

    /**
     * Increment ref counter.
     * To be called for every terminal cell, that holds `idx` as text attributes.
     * <strong i="14">@param</strong> {number} idx
     */
    ref(idx: number): void {
        this.data[idx]++;
    }

    /**
     * Decrement ref counter. Once dropped to 0 the slot will be reused.
     * To be called for every cell that gets removed or reused with another value.
     * <strong i="15">@param</strong> {number} idx
     */
    unref(idx: number): void {
        this.data[idx]--;
        if (!this.data[idx]) {
            let treePart = this.flagTree[this.data[idx + AtlasEntry.FLAGS]];
            treePart.splice(treePart.indexOf(this.data[idx]), 1);
        }
    }
}

let atlas = new TextAttributeAtlas(2);
let a1 = atlas.getSlot({flags: 12, foreground: 13, background: 14});
atlas.ref(a1);
// atlas.unref(a1);
let a2 = atlas.getSlot({flags: 12, foreground: 13, background: 15});
atlas.ref(a2);
let a3 = atlas.getSlot({flags: 13, foreground: 13, background: 16});
atlas.ref(a3);
let a4 = atlas.getSlot({flags: 13, foreground: 13, background: 16});
console.log(atlas);
console.log(a1, a2, a3, a4);
console.log('a1', atlas.getAttributes(a1));
console.log('a2', atlas.getAttributes(a2));
console.log('a3', atlas.getAttributes(a3));
console.log('a4', atlas.getAttributes(a4));

संपादित करें:
रनटाइम पेनल्टी लगभग शून्य है, मेरे बेंचमार्क के लिए ls -lR /usr/lib यह ~2.3 s के कुल रनटाइम में 1 मिसे से कम जोड़ता है। दिलचस्प साइड नोट - कमांड 5 एमबी डेटा के आउटपुट के लिए 64 से कम विभिन्न टेक्स्ट एट्रिब्यूट स्लॉट सेट करता है और पूरी तरह से लागू होने के बाद 20 एमबी से अधिक की बचत करेगा।

बफर में कुछ परिवर्तनों का परीक्षण करने के लिए कुछ प्रोटोटाइप पीआर बनाए (देखें https://github.com/xtermjs/xterm.js/pull/1528#issue-196949371 परिवर्तनों के पीछे सामान्य विचार के लिए):

• पीआर #1528 : विशेषता एटलस
• पीआर #1529 : बफर से wcwidth और charCode हटा दें
• पीआर #1530 : बफर में स्ट्रिंग को कोडपॉइंट्स / सेल स्टोरेज इंडेक्स वैल्यू द्वारा बदलें

@jerch इसके लिए एटलस शब्द से दूर रहना एक अच्छा विचार हो सकता है ताकि "एटलस" का अर्थ हमेशा "बनावट एटलस" हो। स्टोर या कैश जैसा कुछ शायद बेहतर होगा?

ओह ठीक है, "कैश" ठीक है।

मान लीजिए कि मैंने परीक्षण किए गए पीआर के साथ काम किया है। निम्नलिखित मोटे सारांश की पृष्ठभूमि प्राप्त करने के लिए कृपया पीआर टिप्पणियों पर भी एक नज़र डालें।

प्रस्ताव:

1. एक टर्मिनल सेल को स्टाइल करने के लिए आवश्यक सभी चीजों को रखने के लिए AttributeCache बनाएं। शुरुआती रेफरी गिनती संस्करण के लिए #1528 देखें जो असली रंग चश्मा भी रख सकता है। कैश को विभिन्न टर्मिनल इंस्टेंस के बीच भी साझा किया जा सकता है यदि कई टर्मिनल ऐप में आगे की मेमोरी को सेव करने के लिए आवश्यक हो।
2. लघु टर्मिनल सामग्री डेटा स्ट्रिंग रखने के लिए StringStorage बनाएं। # 1530 में संस्करण पॉइंटर अर्थ को "ओवरलोडिंग" करके सिंगल चार स्ट्रिंग्स को स्टोर करने से भी बचाता है। wcwidth यहां ले जाया जाना चाहिए।
3. वर्तमान CharData को [number, string, number, number] से [number, number] सिकोड़ें, जहां संख्याएं पॉइंटर्स (इंडेक्स नंबर) हैं:
   
   
   
   • AttributeCache प्रविष्टि
   
   
   • StringStorage प्रविष्टि
   
   

विशेषताओं के बहुत बदलने की संभावना नहीं है, इसलिए एक 32 बिट संख्या समय के साथ बहुत अधिक मेमोरी बचाएगी। StringStorage सूचक एकल वर्णों के लिए एक वास्तविक यूनिकोड कोडपॉइंट है, इसलिए इसे code CharData प्रविष्टि के रूप में उपयोग किया जा सकता है। वास्तविक स्ट्रिंग तक पहुँचा जा सकता है StringStorage.getString(idx) । चौथे क्षेत्र wcwidth के CharData द्वारा पहुँचा जा सकता है StringStorage.wcwidth(idx) (अभी तक लागू नहीं)। code और wcwidth से CharData (#1529 में परीक्षण) से छुटकारा पाने से लगभग कोई रनटाइम पेनल्टी नहीं है।

1. सिकुड़े हुए CharData को घने Int32Array आधारित बफर कार्यान्वयन में ले जाएं। स्टब क्लास (पूरी तरह कार्यात्मक से दूर) के साथ #1530 में भी परीक्षण किया गया, अंतिम लाभ होने की संभावना है:
   
   
   
   • टर्मिनल बफर का 80% छोटा मेमोरी फ़ुटप्रिंट (5.5 एमबी से 0.75 एमबी तक)
   
   
   • थोड़ा तेज (अभी तक परीक्षण योग्य नहीं है, मुझे 20% - 30% गति प्राप्त करने की उम्मीद है)
   
   
   • संपादित करें: बहुत तेज़ - ls -lR /usr/lib लिए स्क्रिप्ट रनटाइम 1.3s तक गिर गया (मास्टर 2.1s पर है) जबकि पुराना बफर अभी भी कर्सर हैंडलिंग के लिए सक्रिय है, एक बार हटा दिए जाने पर मुझे रनटाइम 1s से नीचे गिरने की उम्मीद है
   
   

डाउनसाइड - चरण 4 काफी काम है क्योंकि इसे बफर इंटरफेस पर कुछ पुनर्विक्रय की आवश्यकता होगी। लेकिन हे - 80% RAM बचाने और फिर भी रनटाइम प्रदर्शन प्राप्त करने के लिए यह कोई बड़ी बात नहीं है, है ना? :मुस्कुराओ:

एक और मुद्दा है जिस पर मैंने ठोकर खाई - वर्तमान खाली सेल प्रतिनिधित्व। इम्हो एक सेल में 3 राज्य हो सकते हैं:

• खाली : प्रारंभिक सेल स्थिति, इसमें अभी तक कुछ भी नहीं लिखा गया है या सामग्री हटा दी गई है। इसकी चौड़ाई 1 है लेकिन कोई सामग्री नहीं है। वर्तमान में blankLine और eraseChar , लेकिन सामग्री के रूप में एक स्थान के साथ।
• शून्य : पूर्ण चौड़ाई वाले चार के बाद सेल, यह इंगित करने के लिए कि दृश्य प्रतिनिधित्व के लिए इसकी कोई चौड़ाई नहीं है।
• सामान्य : सेल में कुछ सामग्री होती है और इसकी दृश्य चौड़ाई होती है (1 या 2, हो सकता है कि जब हम असली ग्रेफेम/बीड़ी सामग्री का समर्थन करते हैं, तो इसके बारे में निश्चित नहीं है)

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

1: 'H', 'e', 'l', 'l', 'o', ' ', 't', 'e', 'r', 'm', 'i', 'n', 'a', 'l', ' '
2: 'w', 'o', 'r', 'l', 'd', '!', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '

ls साथ एक फ़ोल्डर सूची बनाम:

1: 'R', 'e', 'a', 'd', 'm', 'e', '.', 'm', 'd', ' ', ' ', ' ', ' ', ' ', ' '
2: 'f', 'i', 'l', 'e', 'A', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' ', ' '

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

कमोबेश यह अगले प्रश्न की ओर जाता है - एक पंक्ति में वास्तविक सामग्री की लंबाई का निर्धारण कैसे करें (उन कोशिकाओं की मात्रा जिनमें बाईं ओर से कुछ होता है)? एक सरल दृष्टिकोण खाली कोशिकाओं को दाईं ओर से गिनता है, फिर से ऊपर से दोहरा अर्थ यह निर्धारित करना कठिन बनाता है।

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

बीटीडब्ल्यू, इसके ऊपर लपेटे गए स्ट्रिंग के लिए isWrapped समस्या भी होती है, जो कि रीफ्लोइंग आकार बदलने या सही कॉपी और पेस्ट चयन हैंडलिंग के लिए आवश्यक है। इम्हो हम इसे हटा नहीं सकते हैं, लेकिन इसे एटीएम से बेहतर तरीके से एकीकृत करने की आवश्यकता है।

@jerch प्रभावशाली काम! :स्माइली:

1 एक टर्मिनल सेल को स्टाइल करने के लिए आवश्यक सभी चीजों को रखने के लिए एक एट्रीब्यूट कैश बनाएं। शुरुआती रेफरी गिनती संस्करण के लिए #1528 देखें जो असली रंग चश्मा भी रख सकता है। कैश को विभिन्न टर्मिनल इंस्टेंस के बीच भी साझा किया जा सकता है यदि कई टर्मिनल ऐप में आगे की मेमोरी को सेव करने के लिए आवश्यक हो।

#1528 पर कुछ टिप्पणियां कीं।

2 शॉर्ट टर्मिनल कंटेंट डेटा स्ट्रिंग्स को होल्ड करने के लिए एक StringStorage बनाएँ। # 1530 में संस्करण पॉइंटर अर्थ को "ओवरलोडिंग" करके सिंगल चार स्ट्रिंग्स को स्टोर करने से भी बचाता है। wcwidth यहाँ ले जाया जाना चाहिए।

#1530 पर कुछ टिप्पणियां कीं।

4 सिकुड़े हुए चारडाटा को एक सघन Int32Array आधारित बफर कार्यान्वयन में ले जाएँ। स्टब क्लास (पूरी तरह कार्यात्मक से दूर) के साथ #1530 में भी परीक्षण किया गया, अंतिम लाभ होने की संभावना है:

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

एक और मुद्दा है जिस पर मैंने ठोकर खाई - वर्तमान खाली सेल प्रतिनिधित्व। इम्हो एक सेल में 3 राज्य हो सकते हैं

यहां एक बग का उदाहरण दिया गया है जो इस https://github.com/xtermjs/xterm.js/issues/1286 से निकला है, :+1: व्हाइटस्पेस सेल और "रिक्त" सेल में अंतर करने के लिए

बीटीडब्ल्यू, इसके ऊपर लिपटे स्ट्रिंग के लिए भी isWrapped समस्या की ओर जाता है, जो कि रीफ्लोइंग आकार बदलने या सही कॉपी और पेस्ट चयन हैंडलिंग के लिए आवश्यक है। इम्हो हम इसे हटा नहीं सकते हैं, लेकिन इसे एटीएम से बेहतर तरीके से एकीकृत करने की आवश्यकता है।

जब हम https://github.com/xtermjs/xterm.js/issues/622 से निपटते हैं तो मुझे isWrapped दूर जा रहा है क्योंकि परिपत्र सूची में केवल अलिखित पंक्तियां होंगी।

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

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

1. CircularList में 1 + 2 + 3 : 50% बचाता है (~ 5.5 एमबी का ~ 2.8 एमबी)
2. 1 + 2 + 3 + 4 आधे रास्ते - बस लाइन डेटा को टाइप किए गए सरणी में रखें लेकिन पंक्ति अनुक्रमणिका एक्सेस से चिपके रहें: 82% (~ 0.9 एमबी) बचाता है
3. 1 + 2 + 3 + 4 सूचक अंकगणित के साथ पूरी तरह से सघन सरणी: 87% (~ 0.7MB) बचाता है

1. लागू करना बहुत आसान है, बड़े स्क्रॉलबैक के साथ मेमोरी व्यवहार अभी भी खराब स्केलिंग दिखाएगा जैसा कि यहां दिखाया गया है https://github.com/xtermjs/xterm.js/pull/1530#issuecomment -403542479 लेकिन कम विषाक्त स्तर पर
2. लागू करने के लिए थोड़ा कठिन (लाइन स्तर पर कुछ और संकेत की आवश्यकता है), लेकिन Buffer के उच्च एपीआई को बरकरार रखना संभव बना देगा। इम्हो के लिए जाने का विकल्प - बड़ा मेम सेव और अभी भी एकीकृत करना आसान है।
3. विकल्प 2 की तुलना में 5% अधिक मेम सेव, लागू करने में कठिन, सभी एपीआई को बदल देगा और इस प्रकार शाब्दिक रूप से संपूर्ण कोड आधार। इम्हो अधिक अकादमिक हित के लिए या उबाऊ बरसात के दिनों को लागू करने के लिए योग्य।

@Tyriar मैंने webassembly के उपयोग के लिए जंग के साथ कुछ और परीक्षण किए और पार्सर को फिर से लिखा। ध्यान दें कि मेरे जंग के कौशल "जंग खाए" हैं क्योंकि मैं अभी तक इसमें गहरा नहीं हुआ हूं, इसलिए कमजोर जंग कोड का परिणाम निम्नलिखित हो सकता है। परिणाम:

• wasm भाग के भीतर डेटा हैंडलिंग थोड़ा तेज (5 - 10%) है।
• JS से wasm में कॉल कुछ ओवरहेड बनाते हैं और ऊपर से सभी लाभों को खा जाते हैं। वास्तव में यह ~ 20% धीमा था।
• "बाइनरी" जेएस समकक्ष से छोटा होगा (वास्तव में मापा नहीं गया क्योंकि मैंने सभी सामानों को लागू नहीं किया था)।
• JS <--> wasm ट्रांज़िशन आसानी से प्राप्त करने के लिए JS प्रकारों को संभालने के लिए कुछ ब्लोटकोड की आवश्यकता होती है (केवल स्ट्रिंग अनुवाद किया गया)।
• हम JS से wasm अनुवाद से बच नहीं सकते क्योंकि ब्राउज़र DOM और ईवेंट वहाँ पहुँच योग्य नहीं हैं। इसका उपयोग केवल मुख्य भागों के लिए किया जा सकता है, जो अब प्रदर्शन महत्वपूर्ण नहीं हैं (मेम खपत के अलावा)।

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

टीएल; डीआर
xterm.js व्यापक रूप से सामान्य JS सामान जैसे DOM और ईवेंट्स में वेब असेंबली से कुछ भी हासिल करने के लिए है, यहां तक ​​​​कि कोर भागों के पुनर्लेखन के लिए भी।

@jerch अच्छी जांच: स्माइली:

JS से wasm में कॉल कुछ ओवरहेड बनाते हैं और ऊपर से सभी लाभों को खा जाते हैं। वास्तव में यह ~ 20% धीमा था।

मोनाको के मूल निवासी होने के साथ-साथ यह ArrayBuffer s के साथ काम करना जहाँ भी संभव हो हमें perf और सरलता के बीच सबसे अच्छा संतुलन देना चाहिए (आसान, प्रवेश के लिए बाधा)।

@Tyriar RGB डेटा को होल्ड करने के लिए एट्रीब्यूटस्टोरेज के साथ आने की कोशिश करता है। बीएसटी के बारे में अभी तक निश्चित नहीं है, टर्मिनल सत्र में केवल कुछ रंग सेटिंग्स के साथ सामान्य उपयोग के मामले के लिए यह रनटाइम में और भी खराब होगा, हो सकता है कि यह एक रनटाइम ड्रॉप-इन हो, जब रंग किसी दिए गए थॉल्ड को पार कर जाए। इसके अलावा मेमोरी की खपत फिर से बढ़ जाएगी, हालांकि यह अभी भी मेमोरी को बचाएगा क्योंकि विशेषताओं को केवल एक बार संग्रहीत किया जाता है और हर एक सेल के साथ नहीं (सबसे खराब स्थिति में अलग-अलग विशेषताओं वाले प्रत्येक सेल को नुकसान होगा)।
क्या आप जानते हैं कि वर्तमान fg और bg 256 रंगों का मूल्य 8 बिट्स के बजाय 9 बिट आधारित क्यों है? अतिरिक्त बिट का उपयोग किस लिए किया जाता है? यहां: https://github.com/xtermjs/xterm.js/blob/6691f809069a549b4808cd2e055398d2da15db37/src/InputHandler.ts#L1596
क्या आप मुझे attr का वर्तमान बिट लेआउट दे सकते हैं? मुझे लगता है कि स्ट्रिंगस्टोरेज पॉइंटर के लिए "डबल अर्थ" जैसा एक समान दृष्टिकोण स्मृति को और बचा सकता है लेकिन इसके लिए पॉइंटर भेद के लिए आरक्षित होने के लिए attr के एमएसबी की आवश्यकता होगी और किसी अन्य उद्देश्य के लिए उपयोग नहीं किया जाएगा। यह बाद में आगे विशेषता झंडे का समर्थन करने की संभावना को सीमित कर सकता है (क्योंकि FLAGS पहले से ही 7 बिट्स का उपयोग करता है), क्या हम अभी भी कुछ मौलिक झंडे गायब हैं जो आने की संभावना है?

बफर टर्म में 32 बिट attr नंबर को इस तरह पैक किया जा सकता है:

# 256 indexed colors
32:       0 (no RGB color)
31..25:   flags (7 bits)
24..17:   fg (8 bits, see question above)
16..9:    bg
8..1:     unused

# RGB colors
32:       1 (RGB color)
31..25:   flags (7 bits)
24..1:    pointer to RGB data (address space is 2^24, which should be sufficient)

इस तरह भंडारण को केवल दो 32 बिट संख्याओं में आरजीबी डेटा रखने की आवश्यकता होती है जबकि झंडे attr संख्या में रह सकते हैं।

@jerch जिस तरह से मैंने आपको एक ईमेल भेजा है, शायद स्पैम फ़िल्टर द्वारा फिर से खा लिया गया है

क्या आप जानते हैं कि वर्तमान fg और bg 256 रंगों का मान 8 बिट के बजाय 9 बिट पर आधारित क्यों है? अतिरिक्त बिट का उपयोग किस लिए किया जाता है?

मुझे लगता है कि इसका उपयोग डिफ़ॉल्ट fg/bg रंग (जो गहरा या हल्का हो सकता है) के लिए किया जाता है, इसलिए यह वास्तव में 257 रंग है।

https://github.com/xtermjs/xterm.js/pull/756/files

क्या आप मुझे attr का वर्तमान बिट लेआउट दे सकते हैं?

मुझे लगता है कि यह है:

19+:     flags (see `FLAGS` enum)
18..18:  default fg flag
17..10:  256 fg
9..9:    default bg flag
8..1:    256 bg

आप पुराने पीआर https://github.com/xtermjs/xterm.js/pull/756/files में देख सकते हैं कि मैंने ट्रूकलर के लिए क्या किया:

/**
 * Character data, the array's format is:
 * - string: The character.
 * - number: The width of the character.
 * - number: Flags that decorate the character.
 *
 *        truecolor fg
 *        |   inverse
 *        |   |   underline
 *        |   |   |
 *   0b 0 0 0 0 0 0 0
 *      |   |   |   |
 *      |   |   |   bold
 *      |   |   blink
 *      |   invisible
 *      truecolor bg
 *
 * - number: Foreground color. If default bit flag is set, color is the default
 *           (inherited from the DOM parent). If truecolor fg flag is true, this
 *           is a 24-bit color of the form 0xxRRGGBB, if not it's an xterm color
 *           code ranging from 0-255.
 *
 *        red
 *        |       blue
 *   0x 0 R R G G B B
 *      |     |
 *      |     green
 *      default color bit
 *
 * - number: Background color. The same as foreground color.
 */
export type CharData = [string, number, number, number, number];

तो इसमें मेरे 2 झंडे थे; एक डिफ़ॉल्ट रंग के लिए (चाहे सभी रंग बिट्स को अनदेखा करना हो) और एक ट्रूकलर के लिए (चाहे 256 या 16 मिलिट्री कलर करना हो)।

यह बाद में आगे विशेषता झंडे का समर्थन करने की संभावना को सीमित कर सकता है (क्योंकि FLAGS पहले से ही 7 बिट्स का उपयोग करता है), क्या हम अभी भी कुछ मौलिक झंडे गायब हैं जो आने की संभावना है?

हां, हम अतिरिक्त झंडों के लिए कुछ जगह चाहते हैं, उदाहरण के लिए https://github.com/xtermjs/xterm.js/issues/580, https://github.com/xtermjs/xterm.js/issues/1145, मैं कम से कम छोड़ दें> जहां संभव हो 3 बिट्स कहें।

एटीआर के अंदर पॉइंटर डेटा के बजाय, एक और नक्शा हो सकता है जो आरजीबी डेटा के संदर्भ रखता है? mapAttrIdxToRgb: { [idx: number]: RgbData

@Tyriar क्षमा करें, कुछ दिन ऑनलाइन नहीं थे और मुझे डर है कि ईमेल स्पैम फ़िल्टर द्वारा खा लिया गया है। क्या आप कृपया इसे फिर से भेज सकते हैं? :शरमाना:

attrs संग्रहण के लिए अधिक चतुर लुकअप डेटा संरचनाओं के साथ खेला गया। अंतरिक्ष और खोज/सम्मिलित रनटाइम के संबंध में सबसे अधिक आशाजनक पेड़ और एक सस्ता विकल्प के रूप में एक स्कीप्लिस्ट हैं। सिद्धांत रूप में लोल। व्यवहार में न तो मेरी सरल सरणी खोज से बेहतर प्रदर्शन कर सकता है जो मुझे बहुत अजीब लगता है (कोड में कहीं बग?)
मैंने यहां एक परीक्षण फ़ाइल अपलोड की है https://gist.github.com/jerch/ff65f3fb4414ff8ac84a947b3a1eec58 सरणी बनाम एक बाएं झुकाव वाले लाल-काले पेड़ के साथ, जो 10M प्रविष्टियों तक का परीक्षण करता है (जो लगभग पूर्ण पता स्थान है)। एलएलआरबी की तुलना में अभी भी सरणी बहुत आगे है, मुझे संदेह है कि ब्रेक-ईवन भी लगभग 10M होगा। मेरे 7 साल पुराने लैपटॉप पर परीक्षण किया गया, हो सकता है कि कोई इसका परीक्षण भी कर सके और इससे भी बेहतर - मुझे इम्प्लांट/टेस्ट में कुछ बग की ओर इशारा करें।

यहां कुछ परिणाम दिए गए हैं (चल रहे नंबरों के साथ):

prefilled             time for inserting 1000 * 1000 (summed up, ms)
items                 array        LLRB
100-10000             3.5 - 5      ~13
100000                ~12          ~15
1000000               8            ~18
10000000              20-25        21-28

मुझे वास्तव में आश्चर्य होता है कि रैखिक सरणी खोज निचले क्षेत्रों में किसी भी तरह की वृद्धि नहीं दिखाती है, यह ~ 4ms (कैश से संबंधित हो सकती है) पर स्थिर 10k प्रविष्टियों तक है। 10M परीक्षण अपेक्षा से अधिक खराब रनटाइम दोनों के लिए दिखाता है, शायद मेम पेजिंग के कारण। हो सकता है कि जेएस जेआईटी के साथ मशीन से बहुत दूर हो और सभी ऑप्ट/डिप्ट हो रहे हों, फिर भी मुझे लगता है कि वे एक जटिलता कदम को खत्म नहीं कर सकते हैं (हालांकि एलएलआरबी एक _n_ पर भारी लगता है, इस प्रकार ओ के लिए ब्रेक भी बिंदु को आगे बढ़ाता है ( n) बनाम O(logn) ऊपर की ओर)

यादृच्छिक डेटा के साथ बीटीडब्ल्यू अंतर और भी बदतर है।

मुझे लगता है कि इसका उपयोग डिफ़ॉल्ट fg/bg रंग (जो गहरा या हल्का हो सकता है) के लिए किया जाता है, इसलिए यह वास्तव में 257 रंग है।

तो यह 8 पैलेट रंगों में से एक से SGR 39 या SGR 49 है?

एटीआर के अंदर पॉइंटर डेटा के बजाय, एक और नक्शा हो सकता है जो आरजीबी डेटा के संदर्भ रखता है? mapAttrIdxToRgb: { [idx: संख्या]: RgbData

यह अतिरिक्त स्मृति उपयोग के साथ एक और संकेत पेश करेगा। ऊपर दिए गए परीक्षणों के साथ मैंने स्टोरेज में आरजीबी डेटा के साथ उन्हें बचाने के लिए हमेशा एटीआर में झंडे रखने के बीच के अंतर का भी परीक्षण किया। चूंकि अंतर 1M प्रविष्टियों के लिए ~ 0.5ms है, इसलिए मैं इस जटिल attrs सेटअप के लिए नहीं जाऊंगा, इसके बजाय RGB सेट होने के बाद झंडे को स्टोरेज पर कॉपी कर लें। फिर भी मैं प्रत्यक्ष एटीआर बनाम पॉइंटर के बीच 32 वें बिट भेद के लिए जाऊंगा क्योंकि यह गैर आरजीबी कोशिकाओं के लिए भंडारण से बिल्कुल बच जाएगा।

साथ ही मुझे लगता है कि fg/bg के लिए डिफ़ॉल्ट 8 पैलेट रंग वर्तमान में बफर में पर्याप्त रूप से प्रदर्शित नहीं होते हैं। सिद्धांत रूप में टर्मिनल को निम्नलिखित रंग मोड का समर्थन करना चाहिए:

1. SGR 39 + SGR 49 fg/bg के लिए डिफ़ॉल्ट रंग (अनुकूलन योग्य)
2. SGR 30-37 + SGR 40-47 fg/bg के लिए 8 कम रंग पैलेट (अनुकूलन योग्य)
3. SGR 90-97 + SGR 100-107 fg/bg के लिए 8 उच्च रंग पैलेट (अनुकूलन योग्य)
4. SGR 38;5;n + SGR 48;5;n fg/bg के लिए 256 अनुक्रमित पैलेट (अनुकूलन योग्य)
5. SGR 38;2;r;g;b + SGR 48;2;r;g;b fg/bg के लिए RGB (अनुकूलित नहीं)

विकल्प 2.) और 3.) को एक बाइट में एक साथ मर्ज किया जा सकता है (उन्हें एक एकल 16 रंग fg/bg पैलेट के रूप में मानते हुए), 4.) 2 बाइट्स लेता है और 5.) अंत में 6 और बाइट लेगा। रंग मोड को इंगित करने के लिए हमें अभी भी कुछ बिट्स की आवश्यकता है।
इसे बफर स्तर पर प्रतिबिंबित करने के लिए हमें निम्नलिखित की आवश्यकता होगी:

bits        for
2           fg color mode (0: default, 1: 16 palette, 2: 256, 3: RGB)
2           bg color mode (0: default, 1: 16 palette, 2: 256, 3: RGB)
8           fg color for 16 palette and 256
8           bg color for 16 palette and 256
10          flags (currently 7, 3 more reserved for future usage)
----
30

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

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

क्षमा करें, कुछ दिन ऑनलाइन नहीं थे और मुझे डर है कि ईमेल स्पैम फ़िल्टर द्वारा खा लिया गया है। क्या आप कृपया इसे फिर से भेज सकते हैं?

पुन: भेज

ओह बीटीडब्ल्यू सरणी बनाम एलएलआरबी खोज के लिए उपरोक्त संख्याएं बकवास हैं - मुझे लगता है कि यह ऑप्टिमाइज़र द्वारा लूप में कुछ अजीब चीजें करने से खराब हो गया है। थोड़ा अलग परीक्षण सेटअप के साथ यह स्पष्ट रूप से ओ (एन) बनाम ओ (लॉग एन) को बहुत पहले बढ़ रहा है (1000 तत्वों के साथ पेड़ के साथ पहले से ही तेज हो रहा है)।

वर्तमान स्थिति:

• [x] एकाधिक बफर कार्यान्वयन की अनुमति देने के लिए रिफैक्टर https://github.com/xtermjs/xterm.js/pull/1632
• [x] TypedArray- आधारित बफर कार्यान्वयन जोड़ें https://github.com/xtermjs/xterm.js/pull/1641
• [ ] उन सरणियों का पुन: उपयोग करें जिन्हें स्क्रॉलबैक के अंत में काट दिया गया है
• [ ] पुराने बफर कार्यान्वयन को हटा दें (जब हम सुनिश्चित हो जाएं कि नया स्थिर है), टाइप किए गए सरणी बफर तक पहुंच में सुधार करें ताकि यह वस्तुओं के बीच अनावश्यक निर्माण न करे: https://github.com/xtermjs/xterm.js/blob/ 8d16bb6ea2e90312b0efb28bee3f39d3995a906f/src/BufferLine.ts#L153 -L162

बाद में:

• सही रंग https://github.com/xtermjs/xterm.js/issues/484

एक काफी सरल अनुकूलन सरणी-के-सरणी को एक सरणी में फ़्लैट करना है। यानी _N_ कॉलम के BufferLine के बजाय _data _N_ CharData कोशिकाओं की सरणी, जहां प्रत्येक CharData 4 की एक सरणी है, बस एक ही है _4*N_ तत्वों की सरणी। यह _N_ सरणियों के ऑब्जेक्ट ओवरहेड को समाप्त करता है। यह कैश इलाके में भी सुधार करता है, इसलिए यह तेज़ होना चाहिए। एक नुकसान थोड़ा अधिक जटिल और बदसूरत कोड है, लेकिन यह इसके लायक लगता है।

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

स्थान को कम करने के अलावा, प्रति सेल तत्वों की एक चर संख्या का एक फायदा लचीलापन बढ़ा है: अतिरिक्त विशेषताएँ (जैसे 24-बिट रंग), विशिष्ट कोशिकाओं या श्रेणियों के लिए एनोटेशन, ग्लिफ़ या
नेस्टेड डोम तत्व।

आपके विचारों के लिए @PerBothner Thx! हाँ, मैंने पहले से ही सूचक अंकगणित के साथ एकल घने सरणी लेआउट का परीक्षण किया है, यह सबसे अच्छा स्मृति उपयोग दिखाता है। समस्याएँ तब उत्पन्न होती हैं जब आकार बदलने की बात आती है, इसका मूल रूप से पूरे मेमोरी खंड (कॉपी ओवर) का पुनर्निर्माण करना या एक बड़े हिस्से में तेजी से प्रतिलिपि बनाना और भागों को पुन: संरेखित करना है। यह काफी क्स्प है। और मेम सेविंग द्वारा इम्हो उचित नहीं है (ऊपर सूचीबद्ध कुछ खेल के मैदान पीआर में परीक्षण किया गया है, नई बफर लाइन कार्यान्वयन की तुलना में बचत लगभग ~ 10% थी)।

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

बफर में अतिरिक्त सामान जोड़ने के बारे में: हम वर्तमान में यहां वही करते हैं जो अधिकांश अन्य टर्मिनल करते हैं - कर्सर अग्रिम wcwidth द्वारा निर्धारित किया जाता है जो कि pty/termios के विचार के साथ संगत रहना सुनिश्चित करता है कि डेटा को कैसे लेआउट किया जाना चाहिए। इसका मूल रूप से मतलब है कि हम बफर स्तर पर केवल सरोगेट जोड़े और संयोजन वर्णों जैसी चीजों को संभालते हैं। किसी भी अन्य "उच्च स्तर" में शामिल होने के नियम रेंडरर में कैरेक्टर जॉइनर द्वारा लागू किए जा सकते हैं (वर्तमान में https://github.com/xtermjs/xterm-addon-ligatures for ligatures द्वारा उपयोग किया जाता है)। मेरे पास शुरुआती बफर स्तर पर यूनिकोड ग्रेफेम का समर्थन करने के लिए एक पीआर खुला था, लेकिन मुझे लगता है कि हम उस स्तर पर ऐसा नहीं कर सकते क्योंकि अधिकांश पीटीआई बैकएंड के पास इसकी कोई धारणा नहीं है (क्या कोई है?) और हम अजीब चार समूह के साथ समाप्त हो जाएंगे . वही वास्तविक BIDI समर्थन के लिए जाता है, मुझे लगता है कि कर्सर/सेल आंदोलनों को बरकरार रखने के लिए रेंडरर चरण में ग्रेफेम और BIDI बेहतर तरीके से किया जाता है।

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

आपकी विस्तृत प्रतिक्रिया के लिए धन्यवाद।

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

क्या आपका मतलब है: आकार बदलने पर हमें केवल _N_ तत्वों की बजाय _4*N_ तत्वों की प्रतिलिपि बनाना होगा?

सरणी के लिए तार्किक (अलिखित) रेखाओं के लिए सभी कक्षों को समाहित करना समझ में आता है। उदाहरण के लिए 180-वर्ण की रेखा और 80-स्तंभ चौड़ा टर्मिनल मान लें। उस स्थिति में आपके पास समान _4*180_-तत्व _data बफर साझा करने वाले 3 BufferLine उदाहरण हो सकते हैं, लेकिन प्रत्येक BufferLine में एक प्रारंभ ऑफसेट भी होगा।

वैसे मेरे पास एक बड़ी सरणी में सब कुछ था जो [cols] x [rows] x [needed single cell space] द्वारा बनाया गया था। तो यह मूल रूप से अभी भी किसी दिए गए ऊंचाई और चौड़ाई के साथ "कैनवास" के रूप में काम करता है। यह सामान्य इनपुट प्रवाह के लिए वास्तव में मेमोरी कुशल और तेज़ है, लेकिन जैसे ही insertCell / deleteCell का आह्वान किया जाता है (एक आकार ऐसा करेगा), उस स्थिति के पीछे की पूरी मेमोरी जहां कार्रवाई होती है स्थानांतरित करना होगा। छोटे स्क्रॉलबैक (<10k) के लिए यह कोई समस्या भी नहीं है, यह वास्तव में> 100k लाइनों के लिए एक शोस्टॉपर है।
ध्यान दें कि वर्तमान टाइप की गई सरणी इंप को अभी भी उन बदलावों को करना है, लेकिन कम विषाक्त है क्योंकि इसे केवल मेमोरी सामग्री को लाइन एंड तक ले जाना है।
मैंने महंगी पारियों को रोकने के लिए अलग-अलग लेआउट के बारे में सोचा, बकवास मेमोरी शिफ्ट को बचाने के लिए मुख्य क्षेत्र वास्तव में "हॉट टर्मिनल पंक्तियों" से स्क्रॉलबैक को अलग करना होगा (सबसे हाल ही में terminal.rows ) क्योंकि केवल वे ही हो सकते हैं कर्सर जंप और इंसर्ट/डिलीट द्वारा बदला गया।

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

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

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

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

सरणी के लिए तार्किक (अलिखित) रेखाओं के लिए सभी कक्षों को समाहित करना समझ में आता है। उदाहरण के लिए 180-वर्ण की रेखा और 80-स्तंभ चौड़ा टर्मिनल मान लें। उस स्थिति में आपके पास 3 बफ़रलाइन उदाहरण हो सकते हैं जो सभी समान 4*180-तत्व _डेटा बफ़र साझा करते हैं, लेकिन प्रत्येक बफ़रलाइन में एक प्रारंभ ऑफसेट भी होगा।

ऊपर उल्लिखित रीफ्लो की योजना https://github.com/xtermjs/xterm.js/issues/622#issuecomment -375403572 में कैप्चर की गई है, मूल रूप से हम वास्तविक अलिखित बफर और फिर शीर्ष पर एक दृश्य चाहते हैं जो प्रबंधन करता है किसी भी लाइन तक तेजी से पहुंच के लिए नई लाइनें (क्षैतिज आकार बदलने के लिए भी अनुकूलन)।

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

पीआर #1796 के साथ पार्सर को टाइप किया हुआ ऐरे सपोर्ट मिलता है जो सर्वरल आगे के अनुकूलन के लिए द्वार खोलता है, दूसरी ओर अन्य इनपुट एन्कोडिंग के लिए भी।

अभी के लिए मैंने Uint16Array साथ जाने का फैसला किया, क्योंकि यह जेएस स्ट्रिंग्स के साथ आसान आगे और पीछे परिवर्तनीय है। यह मूल रूप से खेल को UCS2/UTF16 तक सीमित करता है, जबकि वर्तमान संस्करण में पार्सर UTF32 (UTF8 समर्थित नहीं है) को भी संभाल सकता है। टाइप किया गया सरणी आधारित टर्मिनल बफर वर्तमान में UTF32 के लिए लेआउट किया गया है, UTF16 -> UTF32 रूपांतरण InputHandler.print । यहाँ से कई दिशाएँ संभव हैं:

• सभी UTF16 बनाएं, इस प्रकार टर्मिनल बफर को UTF16 में भी बदल दें
  हाँ अभी भी यह तय नहीं हुआ है कि कौन सी सड़क यहाँ लेनी है, लेकिन कई बफर लेआउट का परीक्षण किया और निष्कर्ष पर आया, कि एक 32 बिट संख्या वास्तविक चारकोड + wcwidth + संभावित संयोजन अतिप्रवाह (पूरी तरह से अलग) को संग्रहीत करने के लिए पर्याप्त जगह देती है, जबकि 16 बिट ऐसा नहीं कर सकता कीमती चारकोड बिट्स का त्याग किए बिना। ध्यान दें कि हमें UTF16 बफर के साथ भी अभी भी UTF32 रूपांतरण करना है, क्योंकि wcwidth यूनिकोड कोडपॉइंट पर काम करता है। यह भी ध्यान दें कि UTF16 आधारित बफर कम चारकोड के लिए अधिक मेमोरी बचाएगा, वास्तव में BMP प्लेन चारकोड से अधिक शायद ही कभी होगा। यह अभी भी कुछ जांच की जरूरत है।
• पार्सर बनाएं UTF32
  यह काफी सरल है, बस सभी टाइप किए गए सरणियों को 32 बिट संस्करण से बदलें। डाउनसाइड - UTF16 से UTF32 रूपांतरण पहले से ही करना होगा, इसका मतलब है कि संपूर्ण इनपुट परिवर्तित हो जाता है, यहां तक ​​​​कि बचने के क्रम जो कभी भी किसी भी चारकोड> 255 से नहीं बने होंगे।
• wcwidth UTF16 को संगत बनाएं
  हाँ अगर यह पता चला है कि यूटीएफ 16 टर्मिनल बफर के लिए अधिक उपयुक्त है तो यह किया जाना चाहिए।

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

संभावित यूटीएफ 8 इनपुट एन्कोडिंग और आंतरिक बफर लेआउट के संबंध में मैंने एक मोटा परीक्षण किया था। कुल रनटाइम पर कैनवास रेंडरर के बहुत अधिक प्रभाव को रद्द करने के लिए मैंने इसे आगामी वेबग्ल रेंडरर के साथ किया। मेरे ls -lR /usr/lib बेंचमार्क के साथ मुझे निम्नलिखित परिणाम मिलते हैं:

• वर्तमान मास्टर + वेबग्ल रेंडरर:
  

• खेल का मैदान शाखा, #1796, #1811 के कुछ हिस्सों और वेबग्ल रेंडरर पर लागू होता है:
  

खेल का मैदान शाखा पार्सिंग और भंडारण करने से पहले यूटीएफ 8 से यूटीएफ 32 में प्रारंभिक रूपांतरण करता है (रूपांतरण ~ 30 एमएस जोड़ता है)। स्पीडअप मुख्य रूप से इनपुट प्रवाह, EscapeSequenceParser.parse (120 एमएस बनाम 35 एमएस) और InputHandler.print (350 एमएस बनाम 75 एमएस) के दौरान 2 गर्म कार्यों द्वारा प्राप्त किया जाता है। दोनों .charCodeAt कॉल को सहेजकर टाइप किए गए सरणी स्विच से बहुत लाभान्वित होते हैं।
मैंने इन परिणामों की तुलना UTF16 इंटरमीडिएट टाइप एरे से भी की - EscapeSequenceParser.parse थोड़ा तेज है (~ 25 ms) लेकिन InputHandler.print आवश्यक सरोगेट पेयरिंग और कोडपॉइंट लुकअप के कारण wcwidth पीछे रह जाता है
यह भी ध्यान दें कि मैं पहले से ही उस सीमा पर हूं जो सिस्टम ls डेटा (एसएसडी के साथ i7) प्रदान कर सकता है - प्राप्त स्पीडअप रन को तेज करने के बजाय निष्क्रिय समय जोड़ता है।

सारांश:
इम्हो सबसे तेज़ इनपुट हैंडलिंग जो हम प्राप्त कर सकते हैं वह बफर प्रतिनिधित्व के लिए यूटीएफ 8 ट्रांसपोर्ट + यूटीएफ 32 का मिश्रण है। जबकि UTF8 ट्रांसपोर्ट में विशिष्ट टर्मिनल इनपुट के लिए सबसे अच्छा बाइट पैकरेट है और Terminal.write तक बफ़र्स की कई परतों के माध्यम से pty से बकवास रूपांतरणों को हटाता है, UTF32 आधारित बफर डेटा को बहुत तेजी से स्टोर कर सकता है। उत्तरार्द्ध UTF16 की तुलना में थोड़ा अधिक मेमोरी फ़ुटप्रिंट के साथ आता है जबकि UTF16 अधिक अप्रत्यक्ष के साथ अधिक जटिल चार हैंडलिंग के कारण थोड़ा धीमा है।

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

आगामी सच्चे रंग समर्थन के लिए बफर लेआउट:

वर्तमान में टाइप किया गया सरणी आधारित बफर लेआउट निम्नलिखित है (एक सेल):

|    uint32_t    |    uint32_t    |    uint32_t    |
|      attrs     |    codepoint   |     wcwidth    |

जहां attrs में सभी आवश्यक झंडे + 9 बिट आधारित एफजी और बीजी रंग शामिल हैं। codepoint 21 बिट्स का उपयोग करता है (UTF32 के लिए अधिकतम 0x10FFFF है) + 1 बिट संयोजन वर्णों को इंगित करने के लिए और wcwidth 2 बिट्स (0-2 से लेकर) का उपयोग करता है।

अतिरिक्त आरजीबी मूल्यों के लिए जगह बनाने के लिए विचार बिट्स को एक बेहतर पैकेट में पुनर्व्यवस्थित करना है:

• wcwidth को codepoint अप्रयुक्त उच्च बिट्स में डालें
• 32 बिट के साथ एटीआर को एफजी और बीजी समूह में विभाजित करें, अप्रयुक्त बिट्स में झंडे वितरित करें

|             uint32_t             |        uint32_t         |        uint32_t         |
|              content             |            FG           |            BG           |
| comb(1) wcwidth(2) codepoint(21) | flags(8) R(8) G(8) B(8) | flags(8) R(8) G(8) B(8) |

इस दृष्टिकोण का लाभ एक इंडेक्स एक्सेस और अधिकतम द्वारा प्रत्येक मूल्य तक अपेक्षाकृत सस्ती पहुंच है। 2 बिट ऑपरेशन (और/या + शिफ्ट)।

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

|        uint16_t        |              uint16_t               |
|    BMP codepoint(16)   | comb(1) wcwidth(2) attr pointer(13) |

अब हम 4 बाइट्स प्रति सेल + attrs के लिए कुछ जगह तक नीचे हैं। अब attrs को अन्य कोशिकाओं के लिए भी पुनर्नवीनीकरण किया जा सकता है। जय मिशन पूरा हुआ! - एहम, एक सेकंड ...

स्मृति पदचिह्न की तुलना में दूसरा दृष्टिकोण स्पष्ट रूप से जीतता है। रनटाइम के लिए ऐसा नहीं है, तीन प्रमुख कारक हैं जो रनटाइम को बहुत बढ़ाते हैं:

• एटीआर अप्रत्यक्ष
  attr पॉइंटर को दूसरे डेटा कंटेनर में एक अतिरिक्त मेमोरी लुकअप की आवश्यकता होती है।
• एटीआर मिलान
  दूसरे दृष्टिकोण के साथ कमरे को वास्तव में बचाने के लिए दिए गए एटीआर को पहले से सहेजे गए एटीआर के साथ मिलान करना होगा। यह एक बोझिल कार्रवाई है, सभी मौजूदा मूल्यों को देखकर एक सीधा दृष्टिकोण ओ (एन) में सहेजे गए एन एटीआर के लिए है, मेरे आरबी पेड़ के प्रयोग ओ (लॉग एन) की तुलना में अभी भी ओ (लॉग एन) में होने के दौरान लगभग कोई स्मृति लाभ नहीं हुआ है। ओ (1) के साथ 32 बिट दृष्टिकोण में इंडेक्स एक्सेस। इसके अलावा एक पेड़ के पास सहेजे गए कुछ तत्वों के लिए एक खराब रनटाइम होता है (मेरे आरबी पेड़ के साथ कुछ हद तक लगभग 100 प्रविष्टियों का भुगतान करता है)।
• UTF16 सरोगेट पेयरिंग
  16 बिट टाइप की गई सरणी के साथ हमें कोडपॉइंट्स के लिए UTF16 को नीचा दिखाना होगा, जिसने रनटाइम पेनल्टी को भी पेश किया (जैसा कि ऊपर टिप्पणी में बताया गया है)। ध्यान दें कि बीएमपी से अधिक कोडपॉइंट शायद ही कभी होते हैं, फिर भी अकेले जांच करें कि क्या कोई कोडपॉइंट एक सरोगेट जोड़ी बना देगा ~ 50 एमएस जोड़ता है।

दूसरे दृष्टिकोण की कामुकता अतिरिक्त स्मृति बचत है। इसलिए मैंने इसे संशोधित BufferLine कार्यान्वयन के साथ खेल के मैदान की शाखा (ऊपर टिप्पणी देखें) के साथ परीक्षण किया:

हाँ, हम थोड़े समय के लिए वापस आ गए हैं जहां से हमने पार्सर में यूटीएफ 8 + टाइप किए गए सरणी में बदलने से पहले शुरू किया था। मेमोरी का उपयोग ~ 1.5 एमबी से घटकर ~ 0.7 एमबी हो गया (हालांकि 87 सेल और 1000 लाइन स्क्रॉलबैक के साथ डेमो ऐप)।

यहाँ से स्मृति बनाम गति को बचाने की बात है। चूंकि हमने पहले से ही जेएस सरणी से टाइप किए गए सरणी में स्विच करके बहुत मेमोरी बचाई है (सी ++ ढेर के लिए ~ 5.6 एमबी से ~ 1.5 एमबी तक गिरा दिया गया है, जहरीले जेएस हीप व्यवहार और जीसी को काट रहा है) मुझे लगता है कि हमें यहां तेज संस्करण के साथ जाना चाहिए। एक बार स्मृति उपयोग एक बार फिर से एक दबाव वाली समस्या हो जाती है, तब भी हम यहां दूसरे दृष्टिकोण में वर्णित अनुसार अधिक कॉम्पैक्ट बफर लेआउट पर स्विच कर सकते हैं।

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

फिर भी, मैं वास्तव में आपके अभ्यासों को पढ़ने और सीखने का आनंद ले रहा हूं, इसे इतने अच्छे विवरण में साझा करने के लिए धन्यवाद!

@mofux हाँ यह सच है - कोड जटिलता बहुत अधिक है (UTF16 सरोगेट आगे पढ़ा जाता है, इंटरमीडिएट
और चूंकि 32 बिट लेआउट ज्यादातर फ्लैट मेमोरी है (केवल वर्णों के संयोजन को संकेत की आवश्यकता होती है), और अधिक अनुकूलन संभव हैं (# 1811 का भी हिस्सा, अभी तक रेंडरर के लिए परीक्षण नहीं किया गया है)।

एक attr ऑब्जेक्ट को अप्रत्यक्ष करने का एक बड़ा फायदा है: यह बहुत अधिक एक्स्टेंसिबल है। आप एनोटेशन, ग्लिफ़ या कस्टम पेंटिंग नियम जोड़ सकते हैं। आप लिंक जानकारी को संभवतः-क्लीनर और अधिक कुशल तरीके से संग्रहीत कर सकते हैं। शायद एक ICellPainter इंटरफ़ेस को परिभाषित करें जो जानता है कि अपने सेल को कैसे प्रस्तुत करना है, और आप कस्टम गुणों को भी लटका सकते हैं।

एक विचार प्रति बफ़रलाइन दो सरणियों का उपयोग करना है: एक Uint32Array, और ICellPainter सरणी, प्रत्येक सेल के लिए एक तत्व के साथ। वर्तमान ICellPainter पार्सर स्थिति की एक संपत्ति है, और इसलिए जब तक रंग/विशेषता स्थिति नहीं बदलती, तब तक आप उसी ICellPainter का पुन: उपयोग करते हैं। यदि आपको किसी सेल में विशेष गुण जोड़ने की आवश्यकता है, तो आप पहले ICellPainter को क्लोन करें (यदि इसे साझा किया जा सकता है)।

आप सबसे सामान्य रंग/विशेषता संयोजनों के लिए ICellPainter को पूर्व-आवंटित कर सकते हैं - कम से कम डिफ़ॉल्ट रंगों/विशेषताओं के अनुरूप एक अद्वितीय वस्तु है।

शैली में परिवर्तन (जैसे कि डिफ़ॉल्ट अग्रभूमि/पृष्ठभूमि रंग बदलना) प्रत्येक सेल को अपडेट किए बिना, संबंधित ICellPainter इंस्टेंस को अपडेट करके लागू किया जा सकता है।

संभावित अनुकूलन हैं: उदाहरण के लिए एकल-चौड़ाई और दोगुने-चौड़ाई वाले वर्णों (या शून्य-चौड़ाई वाले वर्ण) के लिए विभिन्न ICellPainter उदाहरणों का उपयोग करें। (यह प्रत्येक Uint32Array तत्व में 2 बिट बचाता है।) Uint32Array में 11 उपलब्ध विशेषता बिट्स हैं (यदि हम बीएमपी वर्णों के लिए अनुकूलित करते हैं तो अधिक)। इनका उपयोग सबसे सामान्य/उपयोगी रंग/विशेषता संयोजनों को एन्कोड करने के लिए किया जा सकता है, जिसका उपयोग सबसे सामान्य ICellPainter उदाहरणों को अनुक्रमित करने के लिए किया जा सकता है। यदि ऐसा है, तो ICellPainter सरणी को आलसी रूप से आवंटित किया जा सकता है - यानी केवल तभी जब लाइन में कुछ सेल को "कम-सामान्य" ICellPainter की आवश्यकता होती है।

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

@PerBothner हाँ एक

मैंने कई टेस्टबेड में जो कोशिश की है उस पर कुछ नोट्स:

• सेल स्ट्रिंग सामग्री
  सी ++ से खुद को आकर मैंने सी ++ में समस्या को देखने की कोशिश की, इसलिए मैंने सामग्री के लिए पॉइंटर्स के साथ शुरुआत की। यह एक साधारण स्ट्रिंग पॉइंटर था, लेकिन अधिकांश समय एक सिंगल चार स्ट्रिंग की ओर इशारा करता था। कितना बेकार है। इसलिए मेरा पहला अनुकूलन पते के बजाय कोडपॉइंट को सीधे सहेजकर स्ट्रिंग एब्स्ट्रैक्शन से छुटकारा पाना था (जेएस की तुलना में सी/सी ++ में बहुत आसान)। यह प्रति सेल 12 बाइट्स (स्ट्रिंग पर 8 बाइट्स पॉइंटर + 4 बाइट्स, 32 बिट wchar_t के साथ 64 बिट) को सहेजते हुए पढ़ने/लिखने की पहुंच को लगभग दोगुना कर देता है। सिडेनोट - यहां गति बढ़ाने का आधा कैश से संबंधित है (यादृच्छिक स्ट्रिंग स्थानों के कारण कैश छूट जाता है)। यह सेल सामग्री के संयोजन के लिए मेरे कामकाज के साथ स्पष्ट हो गया - स्मृति का एक हिस्सा जिसे मैंने अनुक्रमित किया था जब codepoint में संयुक्त बिट सेट था (बेहतर कैश इलाके के कारण यहां पहुंच तेज थी, वालग्रिंड के साथ परीक्षण किया गया था)। जेएस को ले जाने के लिए आवश्यक स्ट्रिंग टू नंबर रूपांतरण (हालांकि अभी भी तेज) के कारण गति में वृद्धि बहुत अच्छी नहीं थी, लेकिन मेम की बचत और भी अधिक थी (जेएस प्रकारों के लिए कुछ अतिरिक्त प्रबंधन कक्ष के कारण अनुमान)। समस्या स्पष्ट स्मृति प्रबंधन के साथ संयुक्त सामग्री के लिए वैश्विक StringStorage , जेएस में एक बड़ा एंटीपैटर्न। इसके लिए एक क्विकफिक्स _combined ऑब्जेक्ट था, जो GC को क्लीनअप का प्रतिनिधित्व करता है। यह अभी भी बदलने का विषय है और बीटीडब्ल्यू मनमाने ढंग से सेल से संबंधित स्ट्रिंग सामग्री को स्टोर करने के लिए है (इसे ग्रैफेम्स को ध्यान में रखते हुए किया गया था, लेकिन हम उन्हें जल्द ही नहीं देखेंगे क्योंकि वे किसी बैकएंड द्वारा समर्थित नहीं हैं)। तो यह सेल के आधार पर सेल पर अतिरिक्त स्ट्रिंग सामग्री को स्टोर करने का स्थान है।
• attrs
  attrs के साथ मैंने "बड़ा सोचना" शुरू किया - एक वैश्विक AttributeStorage के साथ सभी टर्मिनल उदाहरणों में उपयोग किए जाने वाले सभी attrs के लिए (देखें https://github.com/jerch/xterm.js/tree/AttributeStorage)। मेमोरी के लिहाज से यह बहुत अच्छा काम करता है, मुख्यतः क्योंकि पीपीएल सच्चे रंग के समर्थन के साथ भी केवल एक छोटे से सेट का उपयोग करता है। प्रदर्शन इतना अच्छा नहीं था - मुख्य रूप से रेफरी गिनती के कारण (प्रत्येक सेल को इस विदेशी मेमोरी में दो बार देखना पड़ता था) और एटीआर मिलान। और जब मैंने जेएस को रेफ चीज को अपनाने की कोशिश की तो यह गलत लगा - जिस बिंदु पर मैंने "स्टॉप" बटन दबाया। इस बीच यह पता चला कि हमने टाइप की गई सरणी पर स्विच करके पहले से ही बहुत सारी मेमोरी और जीसी कॉल को बचाया है, इस प्रकार थोड़ा अधिक महंगा फ्लैट मेमोरी लेआउट यहां इसकी गति लाभ का भुगतान कर सकता है।
  मैंने yday (अंतिम टिप्पणी) का परीक्षण किया, जो कि https://github.com/jerch/xterm.js/tree/AttributeStorage से मिलान के लिए पेड़ के साथ attrs के लिए लाइन स्तर पर एक दूसरी टाइप की गई सरणी थी (आपके ICellPainter विचार की तरह बहुत कुछ) ) खैर परिणाम आशाजनक नहीं हैं, इसलिए मैं अभी के लिए फ्लैट 32 बिट लेआउट की ओर झुक रहा हूं।

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

मेरे लिए टीबीएच यह अफ़सोस की बात है कि एटीआर स्टोरेज के साथ 16 बिट लेआउट खराब प्रदर्शन करता है, मेमोरी के उपयोग को रोकना अभी भी एक बड़ी बात है (esp। जब पीपीएल स्क्रॉल लाइनों का उपयोग करना शुरू करता है> 10k), लेकिन रनटाइम पेनल्टी और कोड जटिलता अधिक वजन उच्च मेम को एटीएम इम्हो की आवश्यकता होती है।

क्या आप ICellPainter विचार के बारे में विस्तार से बता सकते हैं? हो सकता है कि मैंने अब तक कुछ महत्वपूर्ण विशेषता को याद किया हो।

डोमटर्म के लिए मेरा लक्ष्य पारंपरिक टर्मिनल एमुलेटर द्वारा सक्षम की गई समृद्ध बातचीत को सक्षम और प्रोत्साहित करना था। वेब तकनीकों का उपयोग करने से कई दिलचस्प चीजें सक्षम होती हैं, इसलिए केवल एक तेज़ पारंपरिक टर्मिनल एमुलेटर होने पर ध्यान केंद्रित करना शर्म की बात होगी। विशेष रूप से xterm.js (जैसे IDEs के लिए REPLs) के लिए कई उपयोग के मामले सरल पाठ से परे जाकर वास्तव में लाभ उठा सकते हैं। Xterm.js गति पक्ष में अच्छा करता है (क्या कोई गति के बारे में शिकायत कर रहा है?), लेकिन यह सुविधाओं पर इतना अच्छा नहीं करता है (उदाहरण के लिए लोग ट्रूकलर और एम्बेडेड ग्राफिक्स के गायब होने की शिकायत कर रहे हैं )। मुझे लगता है कि लचीलेपन पर थोड़ा और प्रदर्शन पर थोड़ा कम ध्यान देना सार्थक हो सकता है।

_"क्या आप ICellPainter विचार के बारे में विस्तार से बता सकते हैं?"_

सामान्य तौर पर, ICellPainter चरित्र कोड/मान को छोड़कर सभी प्रति-सेल डेटा

interface ICellPainter {
    drawOnCanvas(ctx: CanvasRenderingContext2D, code: number, x: number, y: number);
    // transitional - to avoid allocating IGlyphIdentifier we should replace
    //  uses by pair of ICellPainter and code.  Also, a painter may do custom rendering,
    // such that there is no 'code' or IGlyphIdentifier.
    asGlyph(code: number): IGlyphIdentifier;
    width(): number; // in pixels for flexibility?
    height(): number;
    clone(): ICellPainter;
}

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

मैं हमें यह जांचने के लिए प्रोत्साहित करना चाहता हूं कि क्या हम इसे मोनाको-संपादक की तरह कर सकते हैं (मुझे लगता है कि उन्हें वास्तव में एक स्मार्ट और प्रदर्शन करने वाला तरीका मिला)। बफ़र में ऐसी जानकारी संग्रहीत करने के बजाय, वे आपको decorations बनाने की अनुमति देते हैं। आप एक पंक्ति/स्तंभ श्रेणी के लिए सजावट बनाते हैं और यह उस सीमा तक टिकेगा:

// decorations are buffer-dependant (we need to know which buffer to decorate)
const decoration = buffer.createDecoration({
  type: 'link',
  data: 'https://www.google.com',
  range: { startRow: 2, startColumn: 5, endRow: 2, endColumn: 25 }
});

बाद में एक रेंडरर उन सजावटों को उठा सकता था और उन्हें आकर्षित कर सकता था।

कृपया इस छोटे से उदाहरण को देखें जो दिखाता है कि मोनाको-संपादक एपीआई कैसा दिखता है:
https://microsoft.github.io/monaco-editor/playground.html#interacting -with-the-editor-line-and-inline-decorations

टर्मिनल के अंदर चित्रों को प्रस्तुत करने जैसी चीजों के लिए मोनाको दृश्य क्षेत्रों की एक अवधारणा का उपयोग करता है जिसे यहां एक उदाहरण में (अन्य अवधारणाओं के बीच) देखा जा सकता है:
https://microsoft.github.io/monaco-editor/playground.html#interacting -with-the-editor-listening-to-mouse-events

स्पष्टीकरण और स्केचअप के लिए @PerBothner Thx। उस पर कुछ नोट्स।

हम अंततः भविष्य में इनपुट चेन + बफर को वेबवर्कर में स्थानांतरित करने की योजना बना रहे हैं। इस प्रकार बफर एक अमूर्त स्तर पर काम करने के लिए है और हम पिक्सेल मेट्रिक्स या किसी भी डोम नोड्स की तरह किसी भी रेंडर/प्रतिनिधित्व से संबंधित सामग्री का उपयोग नहीं कर सकते हैं। डोमटर्म के अत्यधिक अनुकूलन योग्य होने के कारण मुझे इसके लिए आपकी ज़रूरतें दिखाई दे रही हैं, लेकिन मुझे लगता है कि हमें इसे एक उन्नत आंतरिक मार्कर एपीआई के साथ करना चाहिए और यहां मोनाको/vscode (वें पॉइंटर्स @mofux के लिए thx) से सीख सकते हैं।
मैं वास्तव में कोर बफर को असामान्य चीजों से साफ रखना चाहता हूं, शायद हमें एक नए मुद्दे के साथ संभावित मार्कर रणनीतियों पर चर्चा करनी चाहिए?

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

|             uint32_t             |        uint32_t         |        uint32_t         |
|              content             |            FG           |            BG           |
| comb(1) wcwidth(2) codepoint(21) | flags(8) R(8) G(8) B(8) | flags(8) R(8) G(8) B(8) |

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

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

कुछ ऐसा है जहां मैं चीजों को जाते हुए देखना चाहता हूं। इन पंक्तियों के साथ मेरे पास एक विचार था कि एम्बेडर्स को डीओएम तत्वों को श्रेणियों में संलग्न करने की अनुमति दी जाए ताकि कस्टम चीजों को खींचा जा सके। मैं इस समय 3 चीजें सोच सकता हूं जिन्हें मैं इसके साथ पूरा करना चाहता हूं:

• ड्रा लिंक इस तरह से रेखांकित करता है (सरल होगा कि वे कैसे महत्वपूर्ण रूप से तैयार किए गए हैं)
• पंक्तियों पर मार्करों को अनुमति दें, जैसे * या कुछ
• कुछ हुआ इंगित करने के लिए पंक्तियों को "फ़्लैश" करने दें

इन सभी को एक ओवरले के साथ हासिल किया जा सकता है और यह एक बहुत ही स्वीकार्य प्रकार का एपीआई है (एक डोम नोड को उजागर करना) और रेंडरर प्रकार के बावजूद काम कर सकता है।

मुझे यकीन नहीं है कि हम एम्बेडर्स को यह बदलने की अनुमति देने के व्यवसाय में उतरना चाहते हैं कि पृष्ठभूमि और अग्रभूमि रंग कैसे खींचे जाते हैं।

@jerch मैं इसे 3.11.0 मील के पत्थर पर रखूंगा क्योंकि मुझे लगता है कि जब हम जेएस सरणी कार्यान्वयन को हटाते हैं तो यह समस्या समाप्त हो जाती है। https://github.com/xtermjs/xterm.js/pull/1796 को भी तब मर्ज करने की योजना है, लेकिन यह मुद्दा हमेशा बफर के मेमोरी लेआउट को बेहतर बनाने के लिए था।

इसके अलावा, बाद में इस पर बहुत सारी चर्चाएं शायद https://github.com/xtermjs/xterm.js/issues/484 और https://github.com/xtermjs/xterm.js/issues/1852 पर बेहतर होंगी। (सजावट की समस्या न होने के कारण बनाया गया)।

@ टायरियर वूट - अंत में बंद: पसीना_स्माइल:

🎉 🕺 🍾