Ember.js: 2.X और 3.X संस्करणों के बीच प्रदर्शन हानि

मेरी मशीन पर क्रोम 81 में कुछ रनों के बाद मुझे मिला:

2.18 सबसे अच्छा समय: 283ms
3.18 सबसे अच्छा समय: 471ms

यह बंद DevTools के साथ चल रहा था।

फिर मैंने एम्बर ऑक्टेन को 3.18 ट्वीडल में परिवर्तित किया:

• घटकों और नियंत्रकों के लिए मूल वर्गों का उपयोग करना।
• @tracked का उपयोग करना और @computed का उपयोग न करना।
• t-r घटक को केवल-टेम्प्लेट में परिवर्तित करना क्योंकि इसमें किसी बैकिंग क्लास की कोई आवश्यकता नहीं थी।
• घटकों को सम्मिलित करते समय कोण ब्रैकेट सिंटैक्स का उपयोग करना।
• नामित आर्ग्स और this. का उपयोग करना जहां टेम्पलेट्स में उपयुक्त है।

उसके बाद मुझे 3.18.1 से मिला सबसे अच्छा समय 276ms था, इसलिए 2.18 नंबर के अनुरूप एक सार्थक सुधार हुआ।

ये प्रदर्शन परीक्षण हालांकि विशेष रूप से वैज्ञानिक नहीं थे, और मैंने जांच नहीं की कि प्रदर्शन के संदर्भ में कौन सा परिवर्तन सबसे महत्वपूर्ण था।

एक मोड़ में प्रोफाइलिंग में बहुत त्रुटि है, क्या हम एक सामान्य एम्बर-क्ली ऐप रेपो (दो संस्करणों में से प्रत्येक के लिए एक शाखा का उपयोग करके) के खिलाफ प्रोफ़ाइल कर सकते हैं?

@rwjblue मैं एक सामान्य एम्बर-क्ली ऐप पर समान परिणाम प्राप्त कर रहा हूं। यहां परीक्षण किया जा सकता

@ richard-viney पर विचार करने के लिए कुछ सुधार हो सकते हैं, लेकिन समस्या यह है कि दोनों संस्करणों में उपयोग किए गए कोई पदावनत कोड नहीं है और प्रदर्शन हानि का अनुभव अस्वीकार्य है।

• टेम्प्लेट-ओनली-कंपोनेंट के उपयोग से प्रदर्शन में वृद्धि हो सकती है, लेकिन कुछ आंतरिक शैलियों की गणना के लिए tr को निश्चित रूप से एक बैकिंग क्लास की आवश्यकता होगी। मुद्दे को प्रदर्शित करने के लिए उदाहरण को सरल बनाया गया था।
• सभी रीफैक्टरिंग के साथ आपको 2.18 के मुकाबले 2 प्रतिशत (283ms -> 276ms) प्रदर्शन लाभ मिलता है। एक मौजूदा 2.18 ऐप को 3.X पर अपग्रेड करने पर विचार करें। सभी घटकों को पुनः प्राप्त करने के लिए केवल 2 प्रतिशत की वृद्धि निश्चित रूप से संभव नहीं है।

@barisnisanci सहमत थे, मुझे यह सुझाव देने का कोई मतलब नहीं था कि उन्नयन के समय महत्वपूर्ण प्रदर्शन प्रतिगमन से बचने के लिए इस तरह के

यह जानना दिलचस्प होगा कि किस एम्बर रिलीज (ओं) ने हस्तक्षेप एलटीएस संस्करणों का परीक्षण करके 3.4, अर्थात 3.8, 3.12 और 3.16 का परीक्षण करके प्रदर्शन प्रतिगमन की शुरुआत की।

@barisnisanci Ember ember serve डिफ़ॉल्ट रूप से विकास मोड में चलते हैं। विकास के दौरान, बहुत सारे अतिरिक्त टूलिंग सक्षम होते हैं जो प्रदर्शन को गंभीरता से प्राप्त कर सकते हैं। हम आमतौर पर इसे एक प्रतिगमन या मुद्दा नहीं मानते हैं, जब तक कि डेवलपर एर्गोनॉमिक्स को प्रभावित करने के लिए इसका बुरा नहीं है। इसलिए सबसे पहले, मैं यह जाँचूँगा कि आप दोनों संस्करण उत्पादन मोड में चला रहे हैं।

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

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

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

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

@pzuraq ने rowsCount:300 और columnsCount:20 साथ रिपॉजिटरी को अपडेट --environment production साथ चल रहे हैं

• 3.18 पहला पेंट: 3489 एमएस
  
• 2.18 पहला पेंट: 2814 एमएस
  

यह भी देखा कि जेएस हीप ने कभी भी 3.18 में रिलीज नहीं किया, लेकिन शायद जीसी पर कुछ बुरी किस्मत।

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

जैसे आपने समग्र मैट्रिक्स का उल्लेख किया है, वैसे ही छोटे बदलावों से महत्वपूर्ण हैं। हालाँकि मामूली अंतर हमारे मामले में एक बड़ी प्रदर्शन गिरावट को जोड़ता है। 3.18 में अपग्रेड करने के बाद हमारा कमर्शियल एप्लिकेशन शुरुआती रेंडर का समय 15 सेकंड से बढ़कर 20 सेकंड हो गया। उम्मीद है कि आप मामूली सैन्य बदलाव के बजाय प्रतिशत के संदर्भ में प्रतिगमन पर विचार करेंगे।

हमारी कंपनी इस समस्या से पीड़ित है। हमने 2.18 से 3.16 तक एम्बर संस्करण को अपडेट किया। तब हमारा रेंडर समय '50' प्रतिशत से अधिक हो गया। जब हम जटिल संरचनाओं का उपयोग करते हैं, तो थोड़े से मीलकॉन्ड परिवर्तनों के बजाय रेंडर के समय का अंतर अधिक स्पष्ट हो जाता है। इस मुद्दे पर कोई अद्यतन? हमारे पास रेंडरमार्क हैं जो रेंडर टाइम में% 50 की बढ़ोतरी दिखाते हैं। फिलहाल 2.18 पर पकड़ बनाने का फैसला किया। यदि हम एक प्रमुख रिफ्लेक्टर की आवश्यकता होगी, तो हम स्विचिंग फ्रेमवर्क पर विचार कर सकते हैं।

@ Caglayan06 क्या आप पुष्टि कर सकते हैं कि आप उत्पादन ध्वज के साथ चल रहे हैं? बस यह सुनिश्चित करना चाहते हैं कि नंबर सेब के लिए सेब हैं!

@ Caglayan06 - यह संभावना नहीं है कि यह कोई एकल चीज है। @Barisnisanci द्वारा प्रदान किया जाने वाला प्रजनन आपके एप्लिकेशन प्रोफ़ाइल से मेल नहीं खाता है। क्या आप अपने ऐप में सामान्य मुद्दे का प्रजनन प्रदान कर सकते हैं (या पुष्टि करें कि ऊपर से @barisnisanci का उदाहरण रेपो आपके उपयोग परिदृश्य / प्रोफ़ाइल आउटपुट का प्रतिनिधित्व करता है)?

क्या आपके पास इस धागे में @barisnisanci की नवीनतम पोस्ट पर कोई टिप्पणी है?
2.18 से 3.16 में अपग्रेड करने के बाद हमारे पास इसी तरह के प्रदर्शन के मुद्दे थे। हमें 40% प्रदर्शन हानि हुई। हम 3.12 पर डाउनग्रेड हो गए, लेकिन केवल उस नुकसान का 20% बचाने में कामयाब रहे, अभी भी लगभग 2.18 जितना अच्छा नहीं है। आपके द्वारा पहले बताए गए तरीके को फिर से तैयार करने में स्विचिंग फ्रेमवर्क जितना समय लगता है। क्या हम इस मुद्दे पर किसी कार्रवाई की उम्मीद करेंगे?

हाल ही में हम ember 3.16.8 में अपग्रेड करते हैं, हमारे पास कोई पूर्ण परीक्षण मामला नहीं है और अभी स्पष्ट प्रदर्शन समस्या नहीं है।
लेकिन मैं जल्द से जल्द प्रदर्शन को हल करने और बंद करने के लिए तत्पर हूं।
>

PS। यानी 11 में अधिक मेमोरी और सीपीयू का उपयोग किया जाता है। कभी-कभी यह ie11 दुर्घटना का कारण बनता है।

@ Caglayan06 - यह संभावना नहीं है कि यह कोई एकल चीज है। @Barisnisanci द्वारा प्रदान किया जाने वाला प्रजनन आपके एप्लिकेशन प्रोफ़ाइल से मेल नहीं खाता है। क्या आप अपने ऐप में सामान्य मुद्दे का प्रजनन प्रदान कर सकते हैं (या पुष्टि करें कि ऊपर से @barisnisanci का उदाहरण रेपो आपके उपयोग परिदृश्य / प्रोफ़ाइल आउटपुट का प्रतिनिधित्व करता है)?

@rwjblue @barisnisanci का उदाहरण मेरे लिए वही काम करता है जो @barisnisanci कहता है।

@ Caglayan06 क्या आप पुष्टि कर सकते हैं कि आप उत्पादन ध्वज के साथ चल रहे हैं? बस यह सुनिश्चित करना चाहते हैं कि नंबर सेब के लिए सेब हैं!

@scottmessinger हाँ, हम उत्पादन ध्वज के साथ चल रहे हैं। हमारे परिणाम @barisnisanci के समान हैं।

हमने अपनी कोड संरचना में सुधार किया। इसने प्रदर्शन को बढ़ाया लेकिन फिर भी यह 2.18 संस्करण के रूप में तेज़ नहीं है। यदि हम 2.18 में परिवर्तन करते हैं तो हमने सर्वोत्तम परिणाम प्राप्त किए।

3.16 कोड सिंटैक्स और नई सुविधाओं को बदलने के लिए हम अपने कोड सिस्टम को ओवरहाल नहीं कर सकते हैं। यह हमारे लिए बहुत महंगा है, क्योंकि हमारी परियोजना बहुत बड़ी है। संभवतः सभी परियोजना को फिर से तैयार करना फ्रेमवर्क को बदलने की तुलना में अधिक महंगा है। क्या इस समस्या पर कोई कार्रवाई की जाएगी?

क्या इस समस्या पर कोई कार्रवाई की जाएगी?

हां बिल्कुल! हमें केवल प्रोफ़ाइल का समय निकालने और यह पता लगाने की आवश्यकता है कि क्या चल रहा है। लेकिन यह वास्तव में किसी पर इंतजार करने की जरूरत नहीं है लेकिन आप to में खुदाई कर रहे हैं

@rwjblue @barisnisanci का उदाहरण मेरे लिए वही काम करता है जो @barisnisanci कहता है।

@ Caglayan06 - हम्म, यह वास्तव में नहीं है जो मैंने पूछा। मुझे पता है कि @ barisnisanci का उदाहरण काम करता है, मैं आपको इसकी समीक्षा करने / इसे प्रोफाइल करने / अपने आवेदन में प्रदर्शन विशेषताओं की तुलना करने और यह देखने के लिए कह रहा हूं कि क्या _way_ उदाहरण काम करता है (और धीमा है) आपके आवेदन से मेल खाता है।

@ Caglayan06 - हम्म, यह वास्तव में नहीं है जो मैंने पूछा। मुझे पता है कि @ barisnisanci का उदाहरण काम करता है, मैं आपको इसकी समीक्षा करने / इसे प्रोफाइल करने / अपने आवेदन में प्रदर्शन विशेषताओं की तुलना करने और यह देखने के लिए कह रहा हूं कि क्या _way_ उदाहरण काम करता है (और धीमा है) आपके आवेदन से मेल खाता है।

@rwjblue i ने हमारे आवेदन में @barisnisanci के रेपो को एकीकृत किया, इसने समान परिणाम दिए। जब हम 3.16 से 3.12 तक संस्करण बदलते हैं, तो हमारे प्रदर्शन को बढ़ावा मिला।
लेकिन अभी भी 2.18 संस्करण के रूप में तेजी से नहीं।

कुछ उदाहरणों के लिए हमारे आवेदन में:

नतीजतन:
यहां तक ​​कि हमने कोड संरचना में सुधार किया, कुल औसत बार प्रस्तुत करना;
2.18 रेंडर समय: 1x सेकंड
3.16 रेंडर समय: 1.6x सेकंड।
3.12 समय प्रस्तुत करना: 1.4x सेकंड।

3.20 में एक वीएम अपग्रेड है, इसलिए मुझे आश्चर्य है कि अगर यहां मदद मिलेगी

@NullVoxPopuli में 3.20.0-beta.2 FP के साथ कोई भाग्य नहीं था: 3.4 सेकंड (3.18 के साथ एक ही)

चूंकि 3.12 बेहतर परिणाम दिखाता है मुझे लगता है कि समस्या को ऑटो ट्रैकिंग के साथ पेश किया जा सकता है। इसके अलावा # 18225 @ Caglayan06 के 3.12 -> 3.16 बेंचमार्क में पूरे एप्लिकेशन प्रदर्शन ड्रॉप पर विचार करने से संबंधित हो सकता है।

हम्म। मुझे आश्चर्य है कि पीछे की ओर कम्प्रेसर सामान कितना ओवरहेड है

कुछ सामान्य प्रश्न:

• Async प्रेक्षक वैकल्पिक सुविधा ध्वज का मूल्य क्या है?
• प्रश्न में एप्लिकेशन QPs का उपयोग करता है?
• क्या नकारात्मक गति सभी मार्गों या केवल कुछ को प्रभावित करती है?

कुछ सामान्य प्रश्न:

• Async प्रेक्षक वैकल्पिक सुविधा ध्वज का मूल्य क्या है?
• प्रश्न में एप्लिकेशन QPs का उपयोग करता है?
• क्या नकारात्मक गति सभी मार्गों या केवल कुछ को प्रभावित करती है?

@rwjblue

1. Async पर्यवेक्षकों के झंडे का उपयोग नहीं करना मुझे लगता है कि डिफ़ॉल्ट 3.12 पर गलत है। 3.16 पर दोनों के साथ टेस्ट किए जाने से बहुत फर्क नहीं पड़ता।
2. QPs व्यापक रूप से प्रमुख मार्गों पर उपयोग किया जाता है। हालांकि प्रदर्शन में गिरावट भी बिना किसी के मनाया गया।
3. सभी मार्ग प्रभावित हैं

इसके अलावा उदाहरण का भंडार उपरोक्त किसी का उपयोग नहीं करता है, लेकिन फिर भी 3.X में धीमा है। रेंडर समय धीरे-धीरे प्रत्येक मामूली संस्करण में बढ़ सकता है इसलिए हम सटीक मुद्दे को इंगित नहीं कर सकते हैं।

Tracerbench की रिपोर्ट बताती है कि 2.18 से 3.18 इस परिदृश्य के लिए ~ 17% को पुनः प्राप्त करता है लेकिन ~ 18% से regresses के बजाय सुधार करता है यदि झिलमिलाता घटक में रूपांतरण किया जाता है।

2.18 से 3.18 कोई अन्य परिवर्तन नहीं
2.18 से 3.18 + ऑक्टेन + ग्लिमर घटक

मुझे इसका अपना एक कांटा मिल गया है, जहाँ मैंने इसके लिए एक स्वचालित धावक जोड़ा है, और धावक को बेहतर बनाने के लिए काम कर रहा हूं ताकि हम जल्दी से संस्करण द्वारा कम कर सकें / यह पता लगाने के लिए प्रतिबद्ध हों कि प्रतिगमन (s) कहां हुआ है। https://github.com/runspired/version-performance/runs/801596557

उन परीक्षणों की स्थापना के लिए @runspired को प्रमुख धन्यवाद! अब जब हमारे पास प्रतिगमन को मज़बूती से मापने के लिए एक ठोस सेटअप है, तो हम इन मुद्दों को ठीक करने की ओर बढ़ा सकते हैं।

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

हालांकि, यह निश्चित रूप से कुछ ऐसा हो सकता है जिसे हमने याद किया। अंत में हम विशिष्ट एप्लिकेशन का परीक्षण कर रहे हैं, जिसमें विशिष्ट उपयोग के मामले और व्यवहार हैं। यह एक मुद्दा हो सकता है क्योंकि हम पकड़ नहीं पाए क्योंकि हमारे टेस्ट केस ऐप्स ने उस कार्यक्षमता का उपयोग नहीं किया है, जो @barisnisanci के प्रजनन की तरह है। यह भी संभव है कि अगर हम उस पुनरुत्पादन में समस्याओं को ठीक करते हैं, तो भी हम दूसरों को ठीक नहीं कर सकते हैं, इसलिए यदि आप प्रतिसादों का सामना कर रहे हैं, तो हम निश्चित रूप से आपके उपयोग के मामले में प्रतिकृतियों की सराहना करेंगे। हम TracerBench सेटअप को आसान बनाने के लिए काम कर रहे हैं ताकि आप इसे स्थानीय स्तर पर परख सकें और @runspired की तरह एक सकें ।

हम यह पता लगाने के लिए खुदाई कर रहे हैं कि सटीक समस्या क्या है और एक समाधान का पता लगाना। सबसे महत्वपूर्ण बात, प्रतिगमन का यह स्तर _any_ API के लिए स्वीकार्य नहीं है, भले ही हम ओकटाइन के साथ गति देख रहे हों। यदि उपयोगकर्ता क्रमिक रूप से उन्नयन और स्विच नहीं कर सकते हैं, तो हम सभी एक साथ पहाड़ पर नहीं चढ़ रहे हैं।

और अपडेट के लिए बने रहें, जैसे ही हम चीजों का पता लगाते हैं, हम आपको बता देंगे!

उनके दुष्ट शांत https://github.com/TracerBench/tracerbench-ppare-action के लिए @runspired को बहुत धन्यवाद

बस इस पर एक त्वरित अपडेट देना चाहता था:

हमने एक TracerBench परीक्षण चलाया , जो @runspired की स्थापना गया , जो कि हमारे सामान्य परीक्षण अनुप्रयोगों में से एक है, यह देखने के लिए कि क्या कोई मेंढक उबल रहा था, जो घटित हुआ था (जैसे छोटे प्रदर्शन परिवर्तन जो कि संस्करण से महत्वहीन था संस्करण, लेकिन एक बड़ी पारी के लिए सारांशित)। यहाँ उस परीक्षण के परिणाम हैं:

एंबर-पर्यवेक्षक 2.18-3.18.pdf

हम इन परिणामों से देख सकते हैं कि दो निश्चित निर्णायक कूद हैं:

1. एम्बर 3.0 से एम्बर 3.1
2. एम्बर 3.16 से एम्बर 3.17

3.17 में प्रतिगमन ग्लिमर वीएम अपग्रेड के कारण है, और हम वर्तमान में इसे कम करने पर ध्यान केंद्रित कर रहे हैं क्योंकि यह काफी हाल ही में है और संभवतः उन अनुप्रयोगों को प्रभावित करना शुरू कर देगा जो एलटीएस चक्र पर जल्द ही अपडेट हो रहे हैं।

3.1 में प्रतिगमन वास्तव में उस समय ज्ञात था, जब कोर टीम के साथ चर्चा की गई थी। यह, मूल रूप से, देशी गेटर्स को सक्षम करके और Object.defineProperty का उपयोग करके किया गया था। इसे नए ब्राउज़र सुविधाओं के साथ रूपरेखा को आगे बढ़ने की अनुमति देने के लिए एक स्वीकार्य प्रतिगमन माना जाता था।

सामान्य तौर पर, इस मुद्दे की शुरुआत में उठाया गया {{each}} परिदृश्य emberobserver.com की तुलना में अधिक और अलग-अलग तरीकों से वापस आ गया है। एक बार जब हमने 3.17 प्रतिगमन में खोदा है, तो हम {{each}} का अनुकूलन करने पर ध्यान केंद्रित करेंगे, यह देखने के लिए कि वहां सामान्य रूप से क्या सुधार किया जा सकता है।

आपके धैर्य के लिए सभी का धन्यवाद!

क्या हमें इस मुद्दे पर अपडेट मिल सकता है? करीब दो महीने हो गए।

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

जैसा कि मैंने पहले बताया था, हम दो अलग-अलग सेटों पर ध्यान केंद्रित कर रहे थे:

1. अगले एलटीएस में अपग्रेड करने की कोशिश कर रहे लोगों के लिए 3.20 एलटीएस रिलीज में उतरने के लिए कम जोखिम वाले रिफ्लेक्टर
2. लंबे समय तक प्रदर्शन में सुधार करने के लिए, बड़े पैमाने पर रिफ्लेक्टर मास्टर पर उतरने के लिए

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

फ़िक्सेस के दूसरे सेट के लिए, हमने अपेक्षाकृत हाल ही में इन्हें उतारा क्योंकि इनमें से बहुत बड़े थे, जिनमें शामिल हैं:

• VM को पूरी तरह से आंतरिक रूप से ऑटोट्रैकिंग करने के लिए अपडेट करना, अतिरिक्त टैग से छुटकारा पाना
• बहुत अधिक जटिलता के साथ कई कार्यान्वयनों के बजाय, एक एकल मोनोमोर्फिक संदर्भ वर्ग का उपयोग करने के लिए वीएम को प्रतिबिंबित करना
• अप्रयुक्त AoT संकलन मोड को हटाना

परिणाम बहुत अच्छे हैं!

results.pdf

यह @barisnisanci से उपरोक्त प्रजनन के साथ, एम्बर के मौजूदा मास्टर की तुलना 2.18 से कर रहा है। अब, जैसा कि पहले उल्लेख किया गया है, यह एक बहुत विशिष्ट उपयोग के मामले के लिए एक बेंचमार्क है, जो अत्यधिक सरल भी है। हमने _not_ को हमारे वास्तविक दुनिया के किसी भी ऐप बेंचमार्क में इतना नाटकीय सुधार देखा, यह समग्र रूप से बहुत अधिक मामूली था। उम्मीद है कि यह @barisnisanci और अन्य अनुप्रयोगों में मदद करेगा और हम निश्चित रूप से उनसे वापस सुनने के इच्छुक हैं!

एम्बर की मास्टर शाखा के साथ ऊपर रेपो का परीक्षण किया गया। फ़र्स्ट पेंट: (3035.7 एमएस) 2.18 से अधिक लगता है (2752.3 एमएस)

इसके अलावा विभिन्न अंगारे संस्करणों के साथ हमारे उत्पादन पर परीक्षण किया गया। मास्टर शाखा हमारे ऐप पर 3.12 की तुलना में 25% से 40% धीमी लगती है। नीचे दिए गए परिणामों के साथ हम प्रमुख रीफैक्टरिंग के बिना एम्बर को अपग्रेड नहीं कर सकते हैं।

@barisnisanci खेद है कि मामला लगता है! जैसा कि मैंने इस धागे में पहले उल्लेख किया है, हम इन परिणामों को एक सांख्यिकीय रूप से ध्वनि तरीके से पुन: पेश करने की आवश्यकता कर रहे हैं ताकि ए की समस्या की पुष्टि करने में सक्षम हो और बी। सुधार की ओर और एक बेहतर समाधान। मैं या तो आपके आवेदन में TracerBench जोड़ने की सलाह देता हूं ताकि आप इन बेंचमार्क को स्वयं चला सकें, या कोई अन्य प्रजनन कर सकें जो अब master पर इस समस्या को प्रदर्शित करता है।