अजीब है कि। आपका नोड संस्करण क्या है?

@ PatSmuk360 क्या आप परीक्षण कर सकते हैं और 3.10.0 की मेमोरी प्रोफाइल प्राप्त कर सकते हैं और देख सकते हैं कि यह अलग है या नहीं?

हम 10 (10.16.3) का नवीनतम संस्करण चला रहे हैं।

पहले स्नैपशॉट ढेर करें:

स्नैपशॉट के बाद ढेर करें:

इसके अलावा मैंने नोड 12.10.0 पर कोशिश की और अनुक्रमिक निर्माण में एक बिंदु पर 587 एमबी मेमोरी उपयोग को मारकर यह बहुत खराब लगता है।

पहले सीपीयू प्रोफाइल:
CPU-20190916T133934.cpuprofile.zip

सीपीयू प्रोफाइल के बाद:
CPU-20190916T134917.cpuprofile.zip

@ PatSmuk360 तो, लंबा और छोटा यह है कि उन संस्करणों के बीच का अंतर यह है कि कोडबेस को ES6 सिंटैक्स में बदल दिया गया था। जो तकनीकी रूप से एक महत्वपूर्ण बदलाव नहीं है, यही वजह है कि यह एक प्रमुख संस्करण नहीं था।

लेकिन ... मेरा संदेह यह है कि ऑब्जेक्ट/सरणी स्प्रेड सिंटैक्स जैसी चीज़ों के लिए कुछ बैबेल रूपांतरण अधिक वर्बोज़ ES5 संस्करणों की तुलना में कम कुशल हैं। इसलिए मैं पूछ रहा था कि क्या आप 3.10.0 का परीक्षण कर सकते हैं, क्योंकि मूल रूप से मैं एक ट्रांसपिल्ड पैकेज का निर्यात कर रहा था जो नोड 6 और ऊपर के साथ संगत था, लेकिन इसने एक विशेष पुस्तकालय के साथ एकीकरण को तोड़ दिया जो क्लास सिंटैक्स को संभाल नहीं सकता था। इसलिए मैं बिना किसी वर्ग के निर्माण के नोड 4 पर चला गया।

यदि हम यह पता लगा सकते हैं कि कौन सा ES5 ट्रांसफ़ॉर्म अच्छा प्रदर्शन नहीं कर रहा है, तो हम सैद्धांतिक रूप से उन बेबेल निर्यात सेटिंग्स को अधिक प्रदर्शन करने वाले निर्यात में सेट कर सकते हैं।

@PatSmuk360 संयोग से, वह split फ़ंक्शन क्या है जिसे इतना समय मिल रहा है?

@ मैथ्यू-डीन ऐसा लगता है कि String.prototype.split । यदि आप अपने chrome devtools में प्रोफ़ाइल खोलते हैं तो आप सभी डेटा रंग कोडित देख सकते हैं। मैं इसके स्रोत के रूप में https://cdn.jsdelivr.net/npm/[email protected]/dist/less.cjs.js से लिंक करने के लिए प्रोफ़ाइल को बदलने की कोशिश कर रहा हूं ताकि बाधाओं का निरीक्षण करना आसान हो। क्या *.cjs.js से *.js फ़ाइल के लिए कोई स्रोत मानचित्र उपलब्ध है? https://cdn.jsdelivr.net/npm/[email protected]/dist/less.min.js.map फ़ाइल .min फ़ाइल को ES6 स्रोत से मैप करती प्रतीत होती है। हो सकता है कि हम स्रोत मानचित्र को देव उपकरण में फीड कर सकें ताकि हम यह पता लगा सकें कि ट्रांसपिलेशन कहां बाधाओं का कारण बनता है।

विशिष्ट https://github.com/less/less.js/blob/cae5021358a5fca932c32ed071f652403d07def8/lib/less/source-map-output.js#L78 में इस लाइन में सीपीयू समय की एक उच्च मात्रा है। लेकिन यह जो ऑपरेशन करता है उसे देखते हुए यह मेरे लिए जगह से बाहर नहीं लगता है।

मुझे ढेर प्रोफाइल के साथ ज्यादा अनुभव नहीं है, लेकिन जो चीज मेरे लिए सबसे अलग है वह है (closures), (system), (array), system / Context की राशि में वृद्धि। इसे सीपीयू प्रोफाइल से जोड़ने की कोशिश में ऐसा लगता है कि इन वस्तुओं के बढ़ने से कचरा इकट्ठा करने में लगने वाले समय में भारी वृद्धि हुई है।

@kevinramharak सामान्य रूप से, _n_ गहराई के साथ एक एएसटी को _n_ गहराई के साथ एक क्रमबद्ध, चपटा आउटपुट ट्री जैसे सीएसएस में परिवर्तित करना बहुत सारे अस्थायी ऑब्जेक्ट निर्माण को शामिल करता है। तो, क्या हो सकता है कि कुछ परिवर्तनों के साथ, यह अतिरिक्त _x_ वस्तुओं की मात्रा जोड़ रहा है। अस्थायी रूप से भी, आप एक घातीय प्रभाव प्राप्त कर सकते हैं जहां प्रत्येक नोड केवल 2-3x ऑब्जेक्ट बना रहा है, नोड्स की संख्या से गुणा करके नियमों को फ़्लैट करने की संख्या से गुणा किया जाता है ... मैं इसे जोड़ रहा था। हम शायद ES6 सिंटैक्स को अनिवार्य रूप से ES5 सिंटैक्स की वाक्यात्मक चीनी के रूप में सोचने के लिए सामान्य रूप से अनुभवहीन थे। (जावास्क्रिप्ट डेवलपर्स शायद सामान्य रूप से इसके लिए दोषी हैं।) वास्तव में, नए सिंटैक्स को ट्रांसपिल करने से ES5 पैटर्न बन सकते हैं जो बहुत अधिक प्रदर्शनकारी नहीं हैं। 99% देवों के लिए, यह कोई बड़ी बात नहीं है क्योंकि वे उस कोड के माध्यम से प्रति सेकंड सैकड़ों या हजारों बार पुनरावृति नहीं कर रहे हैं। लेकिन यह मेरा अनुमान है कि क्या हो रहा है, क्योंकि कोई अन्य बड़े बदलाव नहीं थे।

@kevinramharak पुन: स्रोत रेखाएं - ऐसा इसलिए है क्योंकि मूल कम पार्सर इनपुट के लाइनों/कॉलम को ट्रैक नहीं करता है, इसलिए जब स्रोत मैपिंग जोड़ा गया था, तो यह पता लगाने के लिए अनिवार्य रूप से लाइनों में इनपुट को विभाजित करने की आवश्यकता थी कि इसे कैसे मैप करना चाहिए मूल स्रोत। यह 4.x+ में कोई समस्या नहीं होगी, लेकिन यह समझ में आता है कि यह अब वहां बहुत समय क्यों बिताएगा।

मैं एक ब्राउज़र में less.min.js का उपयोग कर रहा हूं और 3.10.3 मेरे द्वारा पहले उपयोग किए जा रहे 2.7.3 से दो गुना धीमा है। क्रोम और फ़ायरफ़ॉक्स दोनों में।

@PatSmuk360 क्या आप इस शाखा को देख सकते हैं? https://github.com/matthew-dean/less.js/tree/3.11.0

संक्षेप में, ES5 के लिए बेबेल का ट्रांसपिलेशन थोड़े भयानक है, और कक्षाओं को ट्रांसपाइल करने के लिए बहुत सारे Object.defineProperty कॉल का उपयोग करता है। मैंने ट्रांसपिलेशन को टाइपस्क्रिप्ट में बदल दिया, जिसमें फ़ंक्शन प्रोटोटाइप का अधिक स्वच्छ आउटपुट है।

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

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

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

वर्तमान शाखाएं यहां देखी जा सकती हैं: https://github.com/less/less.js/pull/3442

2.7 से अभी भी 2x धीमा।

@alecpl यह अच्छी जानकारी है, लेकिन वास्तव में मैं जानना चाहता हूं कि 3.11.0 3.10 से अधिक सुधार है या नहीं।

इसके बारे में अजीब बात यह है कि, _in theory_, मूल कम कोड को लेबैब के साथ परिवर्तित किया गया था, जो कि बैबेल के विपरीत होना चाहिए। जिसका अर्थ है कि ES5 -> ES6 -> ES5 लगभग समान होना चाहिए, लेकिन स्पष्ट रूप से ऐसा नहीं है। तो मुझे जांच करने की आवश्यकता होगी (जब तक कि किसी और के पास समय न हो, जो स्वागत समर्थन है) बस ES6-> ES5 कोड मूल ES5 कोड से कैसे भिन्न होता है।

@alecpl

इसलिए, मैंने कई तरह के परीक्षण चलाए हैं, और हेडलेस क्रोम में 3.11.0 बनाम 3.10.3 बनाम 3.9.0 बनाम 2.7.3 की बेंचमार्किंग करने में समय बिताया है।

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

आप 3.11.0 शाखा पर grunt benchmark चलाकर स्वयं का परीक्षण कर सकते हैं। वे अलग-अलग रन पर अलग-अलग नंबरों की रिपोर्ट कर सकते हैं, लेकिन यदि आप पर्याप्त बार दौड़ते हैं, तो आपको देखना चाहिए कि समय लगभग बराबर है। इसलिए मुझे नहीं पता कि आपको अपना डेटा कहां मिल रहा है।

@PatSmuk360 क्या आप

मैं आपका कोड खुद नहीं बनाता। मैं नोडज का उपयोग नहीं करता। मैं अपने द्वारा बताए गए दो अलग-अलग संस्करणों के लिए डिस्ट फोल्डर से कम.मिन.जेएस फाइल लेता हूं और उन्हें अपने पेज पर इस्तेमाल करता हूं। फिर कंसोल में मुझे कम कोड द्वारा मुद्रित समय दिखाई देता है। मेरा कम कोड एकाधिक फ़ाइल का उपयोग करता है और आउटपुट फ़ाइल लगभग 100kB minified css है। यह एक "वास्तविक जीवन" बेंचमार्क है। मैं राउंडक्यूब कोड के बारे में बात कर रहा हूं।

क्रोम फ़ायरफ़ॉक्स की तुलना में बहुत तेज़ है, लेकिन दोनों संस्करणों के बीच का अंतर समान है।

@alecpl हम्म .... शायद यह उस विशेष कम कोड के लिए एक विशेष अंतर है। यह सच है कि बेंचमार्क मनमाना है। यदि मेरे पास समय है, तो मैं उन कम फ़ाइलों को बेंचमार्किंग में जोड़ दूंगा।

इस समस्या को स्वचालित रूप से पुराने के रूप में चिह्नित कर दिया गया है क्योंकि इसमें हाल की गतिविधि नहीं है। आगे कोई गतिविधि नहीं होने पर इसे बंद कर दिया जाएगा। आपके योगदानों के लिए धन्यवाद।

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

मैंने 3.11.1 में अपग्रेड किया है और अब वही मेमोरी खपत की समस्या है।
एक मामूली आकार का प्रोजेक्ट वेबपैक और less-loader माध्यम से निर्माण करने के लिए ~600MB RAM ले रहा है।

मैंने इसके परिणामस्वरूप ढेर आवंटन समयरेखा ली है;

Ruleset द्वारा जीवित रखे गए पागल भारी आवंटन का कारण कुछ है।

[संपादित करें]
मैं 3.9 के लिए डाउनग्रेड कर रहा हूँ और उस से एक ढेर आवंटन समयरेखा हथियाने। मैं यह देखने जा रहा हूं कि क्या मुझे कुछ मौलिक रूप से अलग दिखाई देता है।

@ मैथ्यू-डीन
आपके लिए एक संकेत मिला।

3.11 में रूलसेट के लिए सूचीबद्ध अनुचरों में से एक इम्पोर्टमैनेजर है।
3.9 में यह _नहीं मामला_ है।

यदि आयात प्रबंधक द्वारा सब कुछ जीवित रखा जाता है और आयात प्रबंधक संपूर्ण संकलन प्रक्रिया में एक सिंगलटन है। सही है; यह स्मृति उपयोग को महत्वपूर्ण रूप से बढ़ाएगा क्योंकि कुछ भी कचरा एकत्र नहीं किया जा सकता है। मध्यस्थ नियम भी नहीं।

@rjgotten हम्म ...... अगर किसी ऑब्जेक्ट का किसी अन्य ऑब्जेक्ट का संदर्भ है, तो वह जीसी को क्यों रोकेगा? मेरा मतलब है, तकनीकी रूप से, सभी ऑब्जेक्ट प्रोटोटाइप श्रृंखला के माध्यम से सार्वजनिक एपीआई नोड्स के संदर्भ बनाए रखते हैं। यह केवल जीसी को रोकेगा यदि रिवर्स सत्य है यानी कुछ ऑब्जेक्ट प्रत्येक नियम सेट उदाहरण के संदर्भ बनाए रखते हैं।

ऐसा लगता है कि आपने गलत समझा।

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

@rjgotten ओह यह करता है? मुझे आश्चर्य है कि यह परिवर्तन वहां कैसे पहुंचा। मुझे दोष देने की प्रबल संभावना है, या ES6 रिफ्लेक्टर के बारे में कुछ ऐसा है जिसने इसे किया। लेकिन हाँ, यह निश्चित रूप से कर सकता है! जांच के लिए धन्यवाद!

ठीक है, इस कट्टरपंथी विचार के बारे में क्या।

मैंने चेरी के साथ ES6 रूपांतरण को छोड़कर सब कुछ उठाकर एक शाखा बनाई। यह आसान नहीं था, और यह उस सारे काम को न्यूक कर देगा, लेकिन अगर एक Babelified / Typescript'd फ़ाइल मौजूदा मूल JS से बेहतर प्रदर्शन नहीं कर सकती है, तो यह इसके लायक नहीं है।

मुझे नहीं पता कि हम गिट इतिहास को कैसे सुलझाएंगे, लेकिन यहां शाखा है -> https://github.com/less/less.js/tree/release_v3.12.0-RC1। रूपांतरण को रोकना एक बड़ी बात है, इसलिए मुझे लगता है कि यह शाखा तुलना करने के लिए कुछ वास्तविक ठोस बेंचमार्किंग होगी।

मुझे आश्चर्य है कि यह परिवर्तन वहां कैसे पहुंचा। मुझे दोष देने की प्रबल संभावना है, या ES6 रिफ्लेक्टर के बारे में कुछ ऐसा है जिसने इसे किया। लेकिन हाँ, यह निश्चित रूप से कर सकता है! जांच के लिए धन्यवाद!

यह निश्चित रूप से अजीब है। जो मैं समझने में सक्षम था, ऐसा लगता है कि ImportManager किसी तरह ES6 रूपांतरण द्वारा जोड़े गए ग्लूकोड/पॉलीफिल के माध्यम से नियमों के लिए एक अनुचर समाप्त करता है।

मुझे आश्चर्य है कि यहां कोई समाधान है जो बीच में समाप्त होता है। यानी Node.js के लिए ES6 बिल्ड को बनाए रखें लेकिन एक पारदर्शी ब्राउज़र लक्ष्य भी रखें। ES6 रूपांतरण जो जोड़ता है, वह कोड स्पष्टता को दूर करने के लिए एक बहुत बड़ा नुकसान होगा। मैं

@rjgotten

ES6 रूपांतरण जो जोड़ता है, वह कोड स्पष्टता को दूर करने के लिए एक बहुत बड़ा नुकसान होगा।

यह दो कारणों से उतना बुरा नहीं हो सकता जितना लगता है:

1. रोलअप कॉन्फिगरेशन अभी भी मौजूद है, और अगर कोई इस पर शोध करना चाहता है तो इसे कमिट से खींचा जा सकता है।
2. मैं कुछ समय से टाइपस्क्रिप्ट-आधारित कम 4.0 पर सक्रिय रूप से काम कर रहा हूं। मैं इस प्रदर्शन प्रतिगमन को ट्रैक करने के बजाय उस पर अपना समय बिताऊंगा। यह एक ग्राउंड-अप रिफैक्टर है, इसलिए यह किसी भी तरह से करीब नहीं है, लेकिन टीएस की प्रकृति से, इन एक-ऑफ ऑब्जेक्ट म्यूटेशन होने की संभावना नहीं है जो संदर्भों पर पकड़ रखते हैं और जीसी को रोकते हैं। और कोड का पालन करना बहुत स्पष्ट है । तो वह है।

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

क्या कोई ऐसा व्यक्ति है जिसने इसका अनुभव किया है जो अपना कोड साझा करने को तैयार होगा? यह बहुत अच्छा होगा यदि हम वास्तविक दुनिया की परियोजना का उपयोग करके बेंचमार्क कर सकें ताकि हम सुनिश्चित हो सकें कि परिवर्तन मदद कर रहे हैं या नहीं। अगर हम इसे प्राप्त कर सकते हैं तो मैं कोशिश करने और बाधाओं को कम करने में मदद करने के लिए तैयार हूं।

@ मैथ्यू-डीन, एक साइड नोट पर, क्या आपने बेबेल के साथ ढीले मोड में संकलन करने की कोशिश की, यह देखने के लिए कि क्या इसने कोई सैनर-दिखने वाला कोड बनाया है?

@seanCodes मैं परमाणु विकल्प नहीं लेने के लिए हूं, अगर किसी के पास यह जांचने का समय है कि रोलअप/टाइपस्क्रिप्ट का आउटपुट कैसे/क्यों खराब प्रदर्शन करता है, और इन अतिरिक्त स्मृति प्रभाव हैं। यह आंशिक रूप से मूल कोड को देखने, और आउटपुट की तुलना करने और सुराग की तलाश करने का मामला होगा।

मेरे पास एक अनुमान यह है कि कुछ विनाशकारी तर्कों में बहुत अधिक वस्तु-निर्माण बॉयलरप्लेट है।

मूल रूप से, किसी को इस मुद्दे के स्वामी होने के लिए स्वयंसेवा करना होगा।

@ मैथ्यू-डीन, एक साइड नोट पर, क्या आपने बेबेल के साथ ढीले मोड में संकलन करने की कोशिश की, यह देखने के लिए कि क्या इसने कोई सैनर-दिखने वाला कोड बनाया है?

@seanCodes कोड को टाइपस्क्रिप्ट का उपयोग करके संकलित किया गया है, बेबेल नहीं। मेरा विचार था कि टाइप-चेकिंग को मजबूत बनाने के लिए धीरे-धीरे JSDoc प्रकारों में जोड़ा जाए, लेकिन v4 में TS फिर से लिखने के लिए पर्याप्त है, मुझे यकीन नहीं है कि यह आवश्यक है। इसलिए, कोई व्यक्ति Babel बनाम टाइपस्क्रिप्ट (और प्रत्येक के लिए अलग-अलग सेटिंग्स) के साथ प्रयोग कर सकता है यह देखने के लिए कि क्या Babel अधिक प्रदर्शन करने वाला कोड बनाता है। बस इस मुद्दे के प्रति सचेत रहें, जो शुरू में Node.js के लिए एक गैर-ES5 बिल्ड का निर्माण करने के कारण हुआ था: https://github.com/less/less.js/issues/3414

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

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

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

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

@rjgotten

यदि यह सही है, तो आपको कई आयातित फाइलों के साथ एक परीक्षण परियोजना को एक साथ जेरी-रिग करने में सक्षम होना चाहिए, प्रत्येक में कुछ नियम होते हैं और अंतर भी देखते हैं।

"आप" यहाँ महत्वपूर्ण बिट है। मैं

"आप" यहाँ महत्वपूर्ण बिट है। मैं

दुर्भाग्यपूर्ण शब्दों का चयन। मेरा मतलब है कि सामान्य अर्थों में - यानी "कोई भी।"
मैं खुद आगे खुदाई करूंगा, लेकिन मेरे पास पहले से ही बहुत सारी प्लेटें हैं जो वर्तमान में घूम रही हैं।

@rjgotten क्या आप मुझे इस बारे में बेहतर जानकारी दे सकते हैं कि "बहुत सारी आयातित फ़ाइलें" क्या हो सकती हैं? क्या 100 अलग-अलग फाइलें ऐसा करेंगी या हम 1000 की बात कर रहे हैं?

इसके अलावा, आपने पहली बार इस मुद्दे को कैसे नोटिस किया? क्या स्मृति खपत के कारण कोई निर्माण विफल हो गया था या क्या आप स्मृति उपयोग को देख रहे थे? या आपने देखा कि आपकी मशीन धीमी हो रही है?

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

100 या तो करेंगे। यह वास्तविक जीवन की परियोजना के आकार के आसपास है जिस पर मैंने इस मुद्दे पर ध्यान दिया।

मैंने पहली बार इस पर ध्यान दिया जब हमारे कॉर्पोरेट सीआई वातावरण पर चलने वाला एक निर्माण विफल होने लगा। हम उन डॉकटर कंटेनरों को चलाते हैं जिनमें मेमोरी प्रतिबंध कॉन्फ़िगर किए गए हैं।

@rjgotten क्या हमारे पास अभी भी 3.11.3 पर स्मृति समस्या है? मैंने पिछली रिलीज में आयात के भीतर एएसटी के किसी भी कैशिंग (संदर्भ) को हटा दिया था, इसलिए यदि आयात किया जा रहा था, और एएसटी पेड़ उसके भीतर आयोजित किए जा रहे थे, तो इससे स्मृति उपयोग में वृद्धि होगी, लेकिन अगर हम पेड़ों को आयोजित होने से छोड़ देते हैं, क्या यह इसे हल करता है?

@ मैथ्यू-डीन हां, मुद्दा अभी भी 3.11.3 पर मौजूद है।

मैं अवधारणा का प्रमाण बनाने की कोशिश करूंगा लेकिन मेरी थाली में बहुत कुछ है। कुछ अतिरिक्त समय मिलने के बाद मैंने इसे अपनी टू डू लिस्ट में डाल दिया है।

@ मैथ्यू-डीन मैं अपेक्षाकृत बड़ी परियोजना पर इसका परीक्षण करना चाहता हूं, जो पहले असफल रहा था। मुझे कुछ जानने की जरूरत है? क्या मुझे इस शाखा का उपयोग करना चाहिए, https://github.com/less/less.js/tree/release_v3.12.0-RC1 ?

@nfq आप इसे आजमा सकते हैं, लेकिन इस धागे में प्रचलित ज्ञान ES6 रूपांतरण को उड़ा देना नहीं है, जो कि वह शाखा करता है, और इसके बजाय समस्या का ठीक से निदान करने के लिए अधिक जानकारी प्राप्त करें।

संयोग से, मैंने किसी भी लगातार ऑब्जेक्ट को खोजने के प्रयास में संकलन के दौरान less ऑब्जेक्ट का निरीक्षण करने का प्रयास किया, और कोई भी नहीं मिला। ‍♂️

मुझे प्रदर्शन के मुद्दों का भी सामना करना पड़ रहा है। एक ही परीक्षण सूट के लिए:

| संस्करण | समय |
| -- | -- |
| v3.9.0 | ~1.6s |
| v3.10.0~v3.11.1 | ~3.6s |
| v3.11.2+ | ~12s |

यहां चर्चा की गई 3.9.0 → 3.10.0 के अलावा, v3.11.2 पर एक महत्वपूर्ण प्रदर्शन गिरावट प्रतीत होती है। चैंज में यह बदलाव संदेहास्पद लगता है:

3498 आयात प्रबंधक में ट्री कैशिंग निकालें (#3498)

मेरे लिए भी ऐसा।

समान बिल्ड के लिए समय (सभी नोड 10.19.0 पर):

• v3.9: 29.9 सेकंड
• v3.10: 76.0 सेकंड
• v3.12: 89.3 सेकंड

@jrnail23

क्या आपके पास एक रेपो है जो उन परिणामों को प्रदर्शित कर सकता है?

@ मैथ्यू-डीन मेरे पास https://github.com/less/less.js/issues/3434#issuecomment -672580467 के लिए एक है: https://github.com/ecomfe/dls-tooling/tree/master/packages/ कम-प्लगइन- डीएलएस (यह एक मोनोरेपो है, जिसमें एक कम प्लगइन शामिल है।)

क्षमा करें, @ मैथ्यू-डीन, मैं नहीं। वे परिणाम मेरे नियोक्ता के उत्पाद से हैं।

वे परिणाम मेरे नियोक्ता के उत्पाद से हैं।

इसी कारण से मैं कोई फाइल भी नहीं दे सकता। मैं

@rjgotten @ jrnail23 @Justineo - बस उत्सुक है, तो आप ऐसे मामलों में जहां एक ही आयात विभिन्न फाइलों में कई बार आयात किया जाता है की एक संख्या है?

मेरे मामले में हमारे पास एक प्लगइन है जो @import स्टेटमेंट को इंजेक्ट करता है और कस्टम फ़ंक्शंस का एक गुच्छा प्रदान करता है। आयातित फ़ाइल परियोजना के अन्य भागों को आयात करती है जो अंततः 1000+ कम चर उत्पन्न करेगी।

@ मैथ्यू-डीन, हमारे पास एक base.less फ़ाइल है जो सामान्य चीजों (जैसे, रंग चर, टाइपोग्राफी, आदि) को आयात करती है।
हमारे ऐप के कुछ त्वरित ग्रेपिंग से पता चलता है कि एक base.less संदर्भ (यानी, <strong i="8">@import</strong> (reference) "../../../less/base.less"; ) 66 अन्य घटक/फीचर-विशिष्ट less फाइलों द्वारा आयात किया जाता है, और उनमें से कुछ फाइलें हो सकती हैं अन्य घटक/सुविधा-विशिष्ट कम फ़ाइलें भी आयात करें (जो स्वयं base.less संदर्भ दे सकती हैं)।
दिलचस्प बात यह है कि हमारे पास स्पष्ट रूप से एक और less फ़ाइल भी है जो (शायद गलती से?) खुद को एक संदर्भ के रूप में आयात करती है।

@rjgotten @ jrnail23 @Justineo - बस उत्सुक है, तो आप ऐसे मामलों में जहां एक ही आयात विभिन्न फाइलों में कई बार आयात किया जाता है की एक संख्या है?

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

मूल रूप से; प्रत्येक आश्रित को अपनी निर्भरता को सख्ती से आयात करने के लिए स्थापित किया गया है और हम कम संकलक पर भरोसा करते हैं ताकि आयात को सही क्रम में अनुक्रमित और अनुक्रमित किया जा सके और सही सीएसएस आउटपुट सुनिश्चित किया जा सके।

@rjgotten

मैंने इसे पोस्ट किया और हटा दिया (क्योंकि मुझे लगा कि मैंने इसका पता लगा लिया है, लेकिन मैं अभी भी इसे दोहरा नहीं सका), अभी भी लोग क्या रिपोर्ट कर रहे हैं, इसमें कौन सी प्रक्रिया शामिल है, इसे पुन: पेश करने के लिए कोई कदम नहीं हैं।

यहां तक ​​​​कि कुछ भी इतना आसान:

3.11 में रूलसेट के लिए सूचीबद्ध अनुचरों में से एक इम्पोर्टमैनेजर है।

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

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

@Justineo आपके रेपो पर, मेमोरी आकार या संकलन के लिए समय निर्धारित करने के लिए आपने क्या कदम उठाए? मापने के लिए आप क्या उपयोग कर रहे थे?

@Justineo चूंकि आपने कैश हटाने की ओर इशारा किया था (जो शायद एक बुरा विचार था), क्या आप इस शाखा का परीक्षण कर सकते हैं और देख सकते हैं कि क्या यह आपकी निर्माण गति में मदद करता है? https://github.com/less/less.js/tree/cache-restored

आज के प्रयोग/परीक्षण पर कुछ अपडेट देने के लिए:

ग्रंट का shell:test बार

• कम 3.9 - 1.8s
• कम 3.12 (बेबेल-ट्रांसपिल्ड टू ES5) -- 9.2s
• कम 3.12 (बेबेल-ट्रांसपिल्ड टू ES6) -- 3.1s
• कम 3.12 (टाइपस्क्रिप्ट-ES5 में स्थानांतरित) -- 3.2s

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

@Justineo आपके रेपो पर, मेमोरी आकार या संकलन के लिए समय निर्धारित करने के लिए आपने क्या कदम उठाए? मापने के लिए आप क्या उपयोग कर रहे थे?

npm run test बीते हुए कुल समय का उत्पादन करेगा। और अन्य परियोजनाओं में हम 3.12 पर स्विच करने पर ओओएम का अनुभव कर रहे हैं।

यदि हम टाइपस्क्रिप्ट जनरेट किए गए कोड को देखें, तो हमें कुछ ऐसा मिलता है:

Object.defineProperty(exports, "__esModule", { value: true });
var tslib_1 = require("tslib");
var node_1 = tslib_1.__importDefault(require("./node"));
var variable_1 = tslib_1.__importDefault(require("./variable"));
var property_1 = tslib_1.__importDefault(require("./property"));
var Quoted = /** <strong i="6">@class</strong> */ (function (_super) {
    tslib_1.__extends(Quoted, _super);
    function Quoted(str, content, escaped, index, currentFileInfo) {
        var _this = _super.call(this) || this;
        _this.escaped = (escaped == null) ? true : escaped;
        _this.value = content || '';
        _this.quote = str.charAt(0);
        _this._index = index;
        _this._fileInfo = currentFileInfo;
        _this.variableRegex = /@\{([\w-]+)\}/g;
        _this.propRegex = /\$\{([\w-]+)\}/g;
        _this.allowRoot = escaped;
        return _this;
    }

बनाम:

var Node = require('./node'),
    Variable = require('./variable'),
    Property = require('./property');

var Quoted = function (str, content, escaped, index, currentFileInfo) {
    this.escaped = (escaped == null) ? true : escaped;
    this.value = content || '';
    this.quote = str.charAt(0);
    this._index = index;
    this._fileInfo = currentFileInfo;
    this.variableRegex = /@\{([\w-]+)\}/g;
    this.propRegex = /\$\{([\w-]+)\}/g;
};

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

अपडेट करें:

अगर मैं 3.9 परीक्षणों को 3.12 के बराबर रखने की कोशिश करता हूं, तो मुझे अनिवार्य रूप से 1.2s बनाम 1.3s मिलते हैं। इसलिए मैं अब इस अंतर के बारे में निश्चित नहीं हूं क्योंकि परीक्षण बदल गए हैं। इसे ठीक उसी कम फाइलों के खिलाफ चलाना होगा।

@Justineo @rjgotten मैं शायद करने के लिए कुछ टाइपप्रति तोड़ मरोड़ आगे बढ़ाया है जो एक अधिक कुशल निर्माण करते हैं। क्या आप उस शाखा का निर्माण और प्रयास करना चाहते हैं? https://github.com/less/less.js/tree/cache-restored

@ मैथ्यू-डीन धन्यवाद! मैं इसे आज बाद में आजमाऊंगा।

मैंने cache-restored शाखा का परीक्षण किया है और यह v3.11.2+ की तुलना में बहुत तेज़ है, लगभग उसी गति से जैसे v.3.1.0~3.11.1।

@ जस्टिनो

मैंने कैश-पुनर्स्थापित शाखा का परीक्षण किया है और यह v3.11.2+ की तुलना में बहुत तेज़ है, लगभग उसी गति से जैसे v.3.1.0~3.11.1।

खैर, यह आशाजनक है। आइए इस सूत्र में @rjgotten @jrnail23 और अन्य से कुछ प्रतिक्रिया प्राप्त करें। इस थ्रेड को पोस्ट करने के बाद कैश निकालना था (3.11.2); वास्तव में यह कुछ मेमोरी ओवरहेड को हटाने का प्रयास था, लेकिन ऐसे मामलों में जहां आप एक ही फाइल को कई बार आयात कर रहे हैं, यह निश्चित रूप से चीजों को और खराब कर सकता है।

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

@ मैथ्यू-डीन, मुझे cache-restored शाखा का उपयोग करने में कुछ परेशानी हो रही है (मैं इस बारे में बिल्कुल स्पष्ट नहीं हूं कि इसे स्थानीय रूप से उपयोग करने के लिए क्या किया जाना चाहिए, क्योंकि npm link विफल रहता है मुझे)।
क्या आप एक कैनरी/रिलीज़-पूर्व संस्करण प्रकाशित कर सकते हैं जिसे मैं आज़मा सकता हूँ?

@jrnail23

मुझे लगता है कि यह काम कर गया। कम को हटाने और npm i [email protected]+84d40222 साथ इंस्टॉल करने का प्रयास करें

@ मैथ्यू-डीन, मैंने अभी उस संस्करण की कोशिश की है, और यह अभी भी मेरे लिए बुरा है।
ताज़ा वेबपैक बिल्ड (कोई कैशिंग नहीं) के लिए, यह v3.9 के लिए 62.4 सेकंड लेता है, लेकिन v3.13.1 के लिए 121 सेकंड लेता है।
कैश्ड बिल्ड के लिए, v3.9 30 सेकंड लेता है, और v3.13.1 83-87 सेकंड लेता है।

@ jrnail23 क्या आप सभी नोड मॉड्यूल को हटाने और [email protected]+b2049010 स्थापित करने का प्रयास कर सकते हैं

कम 3.9 बेंचमार्क:

कम 4.0.1-अल्फा.0:

कम 4.0.1-अल्फा.2:

@Justineo @rjgotten आप यह भी कोशिश कर सकते हैं?

@ jrnail23 @Justineo @rjgotten

ध्यान दें कि यह एक 4.0 बिल्ड है, इसलिए यदि आपके कोड में ये ब्रेकिंग परिवर्तन हैं तो आपको त्रुटियां आ सकती हैं:

• मिश्रित कॉल के लिए कोष्ठक आवश्यक हैं (उदाहरण .mixin; की अनुमति नहीं है)
• कम का डिफ़ॉल्ट गणित मोड अब पैरेंस-डिवीजन है, इसलिए स्लैश (गणित के रूप में अभिप्रेत) को कोष्ठक में होना चाहिए

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

https://github.com/less/less.js/issues/3434#issuecomment -672580467 के समान परीक्षण सूट का परिणाम:

| संस्करण | समय |
| -- | -- |
| v3.9.0 | ~1.6s |
| v3.10.0~v3.11.1 | ~3.6s |
| v3.11.2+ | ~12s |
| 4.0.1-alpha.2+b2049010 | ~1.6s |

मैं पुष्टि कर सकता हूं कि मेरे विशिष्ट परीक्षण सूट के लिए, प्रदर्शन स्तर v3.9.0 जितना तेज़ हो गया है। बहुत सराहना की मैट! जबकि मैं गणित मोड पर ब्रेक परिवर्तन के बारे में निश्चित नहीं हूं। इसे बदलने से हमारे कई एप्लिकेशन टूट सकते हैं इसलिए हम v3.9.0 पर अटक सकते हैं यहां तक ​​कि प्रदर्शन समस्या भी हल हो गई है।

@ जस्टिनो

जबकि मैं गणित मोड पर ब्रेक परिवर्तन के बारे में निश्चित नहीं हूं।

पिछले गणित व्यवहार को प्राप्त करने के लिए आप math=always मोड में स्पष्ट रूप से संकलित कर सकते हैं। यह सिर्फ एक अलग डिफ़ॉल्ट है।

मुद्दे का टूटना

टीएल; डीआर - वर्ग पैटर्न से सावधान रहें

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

संक्षेप में, ऐसा नहीं है। _(संपादित करें: ठीक है .... यह है और यह नहीं है। यह "विरासत" से आपका क्या मतलब है और आपने इसे कैसे परिभाषित किया है, जैसा कि आप जल्द ही देखेंगे ... पर निर्भर करता है। जावास्क्रिप्ट में प्रोटोटाइप श्रृंखला में "विरासत" बनाएं, और कक्षाएं केवल एक पैटर्न का प्रतिनिधित्व करती हैं, लेकिन वह पैटर्न अन्य सभी से कुछ अलग है, इसलिए टीएस/बेबेल को विशेष कार्यों का उपयोग करके इस पैटर्न की "नकल" करने के लिए सहायक कोड की आवश्यकता है।)_

कम कोड इस तरह दिखता था:

var Node = function() {
  this.foo = 'bar';
}

var Inherited = function() {
  this.value = 1;
}
Inherited.prototype = new Node();

var myNode = new Inherited();

अब कहें कि आप इसे "आधुनिक" जेएस का उपयोग करके फिर से लिखना चाहते हैं। वास्तव में, आप इस प्रक्रिया को स्वचालित कर सकते हैं, जो मैंने किया था, लेकिन किसी भी तरह से मैंने इसे वही लिखा होगा, जो था:

class Node {
  constructor() {
    this.foo = 'bar';
  }
}
class Inherited extends Node {
  constructor() {
    super();
    this.value = 1;
  }
}
var myNode = new Inherited();

वही बात, है ना? दरअसल नहीं। पहला { value: 1 } की संपत्ति के साथ एक वस्तु बनाएगा, और इसकी प्रोटोटाइप श्रृंखला पर, इसमें { foo: 'bar' } वस्तु होगी।

दूसरा, क्योंकि यह Inherited और Node दोनों पर कंस्ट्रक्टर को कॉल करेगा, { value: 1, foo: 'bar' } जैसी संरचना के साथ एक ऑब्जेक्ट बनाएगा।

अब, _user_ के लिए, यह वास्तव में कोई मायने नहीं रखता, क्योंकि आप किसी भी स्थिति में value और foo को myNode से एक्सेस कर सकते हैं। _कार्यात्मक रूप से_, वे वही व्यवहार करते प्रतीत होते हैं।

यहां मैं शुद्ध अटकलों में प्रवेश करता हूं

वी8 जैसे जेआईटी इंजनों के बारे में लेखों में मुझे जो याद है, उससे वस्तु संरचनाएं वास्तव में बहुत महत्वपूर्ण हैं। यदि मैं { value: 1 } , { value: 2 } , { value: 3 } , { value: 4 } जैसी संरचनाओं का एक समूह बनाता हूं, तो V8 उस संरचना का आंतरिक स्थिर प्रतिनिधित्व बनाता है। आप अनिवार्य रूप से एक बार संरचना + डेटा संग्रहीत कर रहे हैं, और फिर डेटा 3 बार।

लेकिन अगर मैं हर बार इसमें अलग-अलग गुण जोड़ता हूं, जैसे: { a: 'a', value: 1 } , { b: 'b', value: 2 } , { c: 'c', value: 3 } , { d: 'd', value: 4 } , तो वे 4 डेटासेट के साथ 4 अलग-अलग संरचनाएं हैं , भले ही वे मूल कक्षाओं के एक ही सेट से बनाए गए हों। जेएस ऑब्जेक्ट का प्रत्येक उत्परिवर्तन डेटा लुकअप को डी-ऑप्टिमाइज़ करता है, और एक वर्ग पैटर्न जो कार्यों में स्थानांतरित हो जाता है (शायद) अधिक-अद्वितीय उत्परिवर्तन का कारण बनता है। (मुझे ईमानदारी से पता नहीं है कि यह ब्राउज़र में मूल वर्ग समर्थन के लिए सच है या नहीं।)

AFAIK, यह भी सच है कि आपके पास किसी ऑब्जेक्ट पर जितनी अधिक संपत्तियां हैं, एक व्यक्तिगत संपत्ति लुकअप में उतना ही अधिक समय लगता है।

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

मैंने पुराने कम सिंटैक्स और टीएस के साथ ट्रांसपाइल किए गए वर्ग पैटर्न का उपयोग करके एक नोड और एक विरासत समारोह के नंगे-हड्डियों के कार्यान्वयन को लिखा। गेट के ठीक बाहर, इनहेरिट किया गया नोड 25% अधिक मेमोरी/संसाधनों की खपत करता है, और इससे पहले कि इनहेरिट किए गए नोड के किसी भी इंस्टेंस को बनाया गया हो।

अब विचार करें कि कुछ नोड्स अन्य नोड्स से प्राप्त होते हैं। इसका मतलब है, कक्षाओं का इन-मेमोरी प्रतिनिधित्व गुणा करना शुरू कर देता है, जैसा कि उनके विरासत में मिला उदाहरण है।

फिर से, यह अटकलें हैं

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

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

मैंने आखिरकार इसका पता कैसे लगाया

ईमानदारी से कहूं तो मुझे कभी भी क्लास पैटर्न पर शक नहीं हुआ। मुझे पता था कि मूल ES5 कोड रिवर्स-बेबेलिफाइड कोड की तुलना में तेजी से चलता था, लेकिन मुझे तीर के कार्यों के आसपास कुछ संदेह था या कहीं सिंटैक्स फैलाना था। मेरे पास अभी भी अप-टू-डेट ES5 शाखा थी, इसलिए एक दिन मैंने फिर से lebab चलाने का फैसला किया, और केवल इन परिवर्तनों का उपयोग करें: let,class,commonjs,template । तभी मुझे पता चला कि इसमें फिर से प्रदर्शन की समस्या है। मुझे पता था कि यह स्ट्रिंग टेम्प्लेटिंग या लेट-टू-वार नहीं था; मैंने सोचा कि शायद आयात-से-आवश्यकता ने कुछ किया है इसलिए मैंने थोड़ी देर के लिए उसके साथ खेला। वह कक्षाएं छोड़ दिया। तो एक झुकाव पर, मैं सभी विस्तारित वर्गों को वापस कार्यात्मक विरासत में लिखता हूं। बम, प्रदर्शन वापस आ गया था।

एक सावधान कहानी

इसलिए! सबक सीखा। यदि आपका प्रोजेक्ट पुराने ES5 कोड पर है, और आप उस "आधुनिक" बैबेल-इफ़ाइड या टाइपस्क्रिप्टेड अच्छाई को तरस रहे हैं, तो याद रखें कि आपने जो कुछ भी ट्रांसपाइल किया, आपने नहीं लिखा।

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

पिछले गणित व्यवहार को प्राप्त करने के लिए आप स्पष्ट रूप से गणित = हमेशा मोड में संकलित कर सकते हैं। यह सिर्फ एक अलग डिफ़ॉल्ट है।

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

विस्तृत विवेचन के लिए धन्यवाद!

मैंने संकलित आउटपुट में Object.assign का उपयोग देखा, जिसका अर्थ है कि यह केवल उन ब्राउज़रों में काम करता है जो मूल ES class सिंटैक्स का समर्थन करते हैं जब तक कि पॉलीफ़िल की आवश्यकता नहीं होती है। तो अगर हम पुराने वातावरण (जैसे IE11, नोड 4, ...) के लिए समर्थन छोड़ने का इरादा रखते हैं, तो क्या हम ES5 तक ट्रांसपाइल किए बिना मूल सिंटैक्स का उपयोग कर सकते हैं?

साथ ही, मुझे लगता है कि यह बेहतर है अगर हम प्रदर्शन गिरावट और ब्रेकिंग परिवर्तनों के फिक्स को अलग कर सकते हैं, जिसका मतलब है कि प्रदर्शन फिक्स को v3 में लैंड करना और केवल v4 में ब्रेकिंग परिवर्तन शामिल करना है।

@ मैथ्यू-डीन
तथ्य यह है कि ईएस वर्ग अपराधी हैं पागल डरावना है।
विस्तृत विवेचन के लिए धन्यवाद।

दिखाने के लिए जाता है: _विरासत पर संरचना_

हालांकि एफवाईआई; यदि आप एक क्लीनर प्रोटोटाइप विरासत श्रृंखला चाहते हैं तो आपको वास्तव में इसे अपने उदाहरण से थोड़ा अलग करना चाहिए।
यदि आप इस तरह Object.create उपयोग करते हैं:

var Node = function() {
  this.foo = 'bar';
}
Node.prototype = Object.create();
Node.prototype.constructor = Node;

var Inherited = function() {
  Node.prototype.constructor.call( this );
  this.value = 1;
}
Inherited.prototype = Object.create( Node.prototype );
Inherited.prototype.constructor = Inherited;

var myNode = new Inherited();

फिर आप गुणों को उन उदाहरणों पर समतल करते हैं जो तब समान आकार साझा करते हैं; प्रोटोटाइप आकार साझा करते हैं; _और_ आप प्रत्येक संपत्ति के उपयोग के लिए प्रोटोटाइप श्रृंखला को क्रॉल करने से बचते हैं। मैं

@ जस्टिनो

मैंने संकलित आउटपुट में Object.assign का उपयोग देखा, जिसका अर्थ है कि यह केवल उन ब्राउज़र में काम करता है जो मूल ES वर्ग सिंटैक्स का समर्थन करते हैं जब तक कि पॉलीफ़िल की आवश्यकता नहीं होती है। तो अगर हम पुराने वातावरण (जैसे IE11, नोड 4, ...) के लिए समर्थन छोड़ने का इरादा रखते हैं, तो क्या हम ES5 तक ट्रांसपाइल किए बिना मूल सिंटैक्स का उपयोग कर सकते हैं?

मुझे नहीं लगता कि यह बिल्कुल सही है यानी ऑब्जेक्ट.असाइन कक्षाओं के कार्यान्वयन से कुछ समय पहले उतरा लेकिन आपकी बात मान ली गई। मैं बस [Something].prototype.property को बार-बार लिखने से बचने की उम्मीद कर रहा था: /

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

साथ ही, मुझे लगता है कि यह बेहतर है अगर हम प्रदर्शन गिरावट और ब्रेकिंग परिवर्तनों के फिक्स को अलग कर सकते हैं, जिसका मतलब है कि प्रदर्शन फिक्स को v3 में लैंड करना और केवल v4 में ब्रेकिंग परिवर्तन शामिल करना है।

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

@rjgotten AFAIK वही है जो एक वर्ग पैटर्न करने वाला है, ठीक उसी तरह जैसा आपने इसे परिभाषित किया है। जब तक मैं एक महत्वपूर्ण अंतर नहीं देख रहा हूँ। तो ‍️। यदि यह अच्छा प्रदर्शन कर रहा है तो मैं लेस के नोड इनहेरिटेंस पैटर्न को फिर से बदलने की कोशिश नहीं करने जा रहा हूं (इसके अलावा मैं इस Object.assign कॉल को @Justineo के सुझाव के अनुसार हटा सकता हूं।)

@Justineo @rjgotten आप इस प्रयास कर सकते हैं: [email protected]+b1390a54

बस कोशिश की:

| संस्करण | समय |
| -- | -- |
| v3.9.0 | ~1.6s |
| v3.10.0~v3.11.1 | ~3.6s |
| v3.11.2+ | ~12s |
| 4.0.1-alpha.2+b2049010 | ~1.6s |
| 3.13.0-alpha.10+b1390a54 | ~4.7s |

पी.एस. Node.js v12.13.1 के साथ परीक्षण किया गया।

मैं क्या हूँ।

अलग बेंचमार्क स्थापित करने का समय नहीं था।
लेकिन एक एकीकरण परीक्षण परिप्रेक्ष्य से, यहां कुछ वास्तविक दुनिया की संख्याएं हैं: उत्पादन-ग्रेड वेबपैक प्रोजेक्ट के संचयी परिणाम जो कम का उपयोग करते हैं।

संस्करण | समय | पीक मेमोरी
:--------------------------|----------:|---------------:
3.9 | 35376ms | 950MB
3.11.3 | 37878ms | 920एमबी
3.13.0-alpha.10+b1390a54 | 34801ms | 740MB
3.13.1-अल्फा.1+84डी40222 | 37367ms | 990MB
4.0.1-alpha.2+b2049010 | 35857ms | 770एमबी

मेरे लिए 3.13.0 _best_ परिणाम देता है...

3.11.3 में यह भी प्रतीत होता है कि भगोड़ा स्मृति उपयोग नहीं है जो मैंने 3.11.1 संस्करण के साथ पहले देखा था।
लेकिन 4.0.1 और 3.13.0 बीटा अभी भी बेहतर हैं।

कैश को पुनर्स्थापित करने वाला 3.13.1 मेरे वास्तविक-विश्व संकलन समय को बेहतर बनाने में मदद नहीं करता है और केवल स्मृति उपयोग को बढ़ाता है।

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

यहां ट्री पर इनहेरिटेंस परिवर्तन के साथ एक प्रकाशित बिल्ड है, और पार्स ट्री कैश को पुनर्स्थापित किया गया है: [email protected]+e8d05c61

परीक्षण का मामला

https://github.com/ecomfe/dls-tooling/tree/master/packages/less-plugin-dls

परिणाम

| संस्करण | समय |
| -- | -- |
| v3.9.0 | ~1.6s |
| v3.10.0~v3.11.1 | ~3.6s |
| v3.11.2+ | ~12s |
| 4.0.1-अल्फा.2| ~1.6s |
| 3.13.0-अल्फा.10| ~4.7s |
| 3.13.0-अल्फा.12 | ~1.6s |

Node.js संस्करण

v12.13.1

मेरे लिए यह संस्करण पूरी तरह से काम करता प्रतीत होता है। मैं अपने सहयोगियों से कोशिश करने और सत्यापित करने के लिए कहूंगा।

मेरे लिए alpha.10 से थोड़ा खराब काम करता है, लेकिन यह केवल भिन्नता भी हो सकता है:

संस्करण | समय | पीक मेमोरी
:--------------------------|----------:|---------------:
3.9 | 35376ms | 950MB
3.11.3 | 37878ms | 920एमबी
3.13.0-alpha.10+b1390a54 | 34801ms | 740MB
3.13.0-alpha.12+e8d05c61 | 36263ms | 760एमबी
3.13.1-अल्फा.1+84डी40222 | 37367ms | 990MB
4.0.1-alpha.2+b2049010 | 35857ms | 770एमबी

@ मैथ्यू-डीन, ऐसा लगता है कि मेरा कोड अभी तक 4.0.1-alpha.2+b2049010 परिवर्तनों के अनुकूल नहीं है। मैं देखूंगा कि क्या मैं अपने मुद्दों को हल कर सकता हूं और इसे आजमा सकता हूं।

@rjgotten हाँ, आपके टेस्ट केस के लिए अंतर मामूली लगता है।

मुझे लगता है कि इसका नतीजा यह है कि मैं 3.x और 4.0 दोनों रिलीज तैयार कर सकता हूं। मैं इस मुद्दे को अनसुलझे के साथ 4.0 धक्का देने के लिए खुजली नहीं कर रहा था। शुक्र है, ऐसा लग रहा है कि यह हो गया है।

दूसरी वस्तु जो मैं करूँगा वह किसी के लिए भी एक मुद्दा है जिसे हथियाने के लिए एक सीआई पाइपलाइन में डालना है जो कम विफल हो जाती है यदि यह एक निश्चित बेंचमार्क सीमा से नीचे आती है।

@ jrnail23 यह बहुत अच्छा होगा यदि आप 4.0 अल्फा को चलाने के लिए संशोधित कर सकते हैं, लेकिन क्या आप इस बीच [email protected]+e8d05c61 आज़मा सकते हैं?

@ मैथ्यू-डीन, मुझे अपने निर्माण के लिए निम्नलिखित मिल रहे हैं:

• v3.9: 98 सेकंड
• v3.10.3: 161 सेकंड
• v3.13.0-alpha.12: 93-96 सेकंड

तो ऐसा लगता है कि आप वापस वहीं आ गए हैं जहां आप होना चाहते हैं! अच्छा काम!

अच्छा काम!

हाँ, मैं दूसरे स्थान पर जा रहा हूँ; तीसरा; और चौथा वह।
यह एक बुरा, बुरा प्रदर्शन प्रतिगमन था जिसे साफ करने के लिए वास्तव में एक _lot_ प्रयास करना पड़ा।

काम_बहुत अच्छा_किया।

ठीक है टीम! मैं 3.x बिल्ड प्रकाशित करने जा रहा हूं, और कुछ समय बाद, शायद अगले सप्ताह, 4.0 प्रकाशित करें। दोनों के पास अब प्रदर्शन सुधार होना चाहिए। डीबग करने में मदद करने वाले सभी लोगों को धन्यवाद!

वैसे, मैं वर्तमान में कम.जेएस कोडबेस को टाइपस्क्रिप्ट में बदलने की प्रक्रिया में हूं, और कुछ प्रदर्शन ट्यूनिंग/रीफैक्टरिंग करने के अवसर का उपयोग करने की योजना बना रहा हूं। अगर किसी को दिलचस्पी है तो मैं मदद के लिए तैयार हूं! https://github.com/matthew-dean/less.js/compare/master...matthew-dean :next

कुछ खास जहां आप कुछ अतिरिक्त आंखें पसंद करेंगे? पीआर बहुत बड़ा है, इसलिए मुझे नहीं पता कि कहां से शुरू करना है

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