Aspnetcore: एओटी संकलन

mono-wasm . की स्थिति पर अनुवर्ती कार्रवाई

क्या आप कोई ऐसा मुद्दा जानते हैं जहां हम इस पर प्रगति को ट्रैक कर सकते हैं?

वर्तमान दुभाषिया मोड बहुत धीमा है।
https://dotnetfiddle.net/JUpsRT

.NET 300 एमएस
WASM: १३१५५ एमएस

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

@ danroth27 मोनो आईएल दुभाषिया और वर्तमान mono.wasm संस्करण के बीच प्रदर्शन अंतर लगभग 5-10x है। कुल मिलाकर mono.wasm लगभग 50-80x है और IL दुभाषिया मूल .NET कोर कंसोल एप्लिकेशन की तुलना में लगभग 10x धीमा है।

तो दुभाषिया अभी भी समग्र रूप से बहुत तेज़ नहीं है और WebAssembly उसके ऊपर और भी अधिक ओवरहेड जोड़ता है।

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

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

क्या वर्तमान में Blazor परियोजनाओं के लिए AoT संकलन को सक्षम करने का कोई व्यवहार्य तरीका है? मैं ब्लॉग पोस्ट पढ़ता रहता हूं जो दावा करते हैं कि Blazor में पहले से ही AoT मोड है; यदि यह सच है, तो क्या कोई कृपया किसी लेख की ओर संकेत कर सकता है जिसमें बताया गया है कि इसे कैसे सक्षम किया जाए?

@TheFanatr एओटी संकलन इस सुविधा का समर्थन करने वाले मोनो पर निर्भर है। जहाँ तक मेरा विषय पर अंतिम अद्यतन बता सकते में @migueldeicaza से था Blazor Gitter ।

मिगुएल डी इकाज़ा (2018-06-08 19:01):
हम इस पर काम कर रहे हैं। क्या हुआ यह है:
दुभाषिया "एम्सस्क्रिप्टन" का उपयोग कर रहा है जिसमें काफी पूर्ण libc है जिस पर हम भरोसा कर सकते हैं। और हमारा AOT इंजन शुद्ध LLVM पर बनाया गया था, जिसके लिए हमें पूर्ण libc लिखने की आवश्यकता होती है। उत्तरार्द्ध आदर्श स्थान है, क्योंकि हमें देशी लिंकर्स और तत्काल एलएलवीएम समर्थन आदि मिलते हैं। लेकिन woudl हमें उस libc को लिखने के रास्ते पर भेज देगा।
तो अल्पावधि के लिए, हम एओटी कंपाइलर को एम्स्क्रिप्ट करने के लिए आगे बढ़ रहे हैं, सुनिश्चित करें कि हम संगतता बनाए रखें। हालांकि नकारात्मक पक्ष यह है कि एम्स्क्रिप्टन टूलिंग पुरानी है, इसलिए एलएलवीएम लिंकर जैसे कई बेहतर टुकड़े उपलब्ध नहीं हैं। इसलिए हम उन चीजों पर काम कर रहे हैं।
मूल रूप से, हमने कुछ किया था, लेकिन हमें अपने दम पर सब कुछ लिखने और अनुकरण करने के लिए मजबूर किए बिना हमारे पास जो कुछ भी है उसके साथ काम करने के लिए खरोंच से शुरू करना पड़ा। हम उन दोनों को मिलाने की कोशिश कर सकते थे, लेकिन यह भी एक बड़ा प्रयास है। इसलिए हमें लगता है कि हम यहां और वहां कुछ कलात्मक हैक्स के माध्यम से अभी के लिए एम्स्क्रिप्टन कर सकते हैं।

तो संक्षेप में, वे इस पर काम कर रहे हैं, लेकिन मौजूदा सार्वजनिक बिल्ड के साथ ऐसा करने का कोई अच्छा विकल्प नहीं है।

CoreRT में कुछ बहुत अच्छी प्रगति की सूचना मिली है !!

https://github.com/dotnet/corert/issues/4659#issuecomment -425690500

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

@honkmother AoT पर https://github.com/mono/mono रेपो में mono.wasm लोग काम कर रहे हैं। मुझे यकीन है कि वे आपकी मदद के लिए रोमांचित होंगे! यह समस्या उनके काम के तैयार होने के बाद खपत को ट्रैक करती है।

मुझे लगता है कि मेरे पास कुछ हद तक संबंधित प्रश्न है लेकिन यह अच्छी तरह से सोचा नहीं गया है और बुरी तरह से लिखा गया है- मैं ILRepack और Blazor के साथ प्रयोग कर रहा हूं, और अधिकांश डीएलएस को एक साथ एक मोनोलिथिक ब्लॉब में पैकेज करने में कामयाब रहा हूं। क्या आप लोग किसी भी बिंदु पर आम पुस्तकालयों को एक ही डीएल के रूप में पैकेज करना चाहते हैं?

@honkmother वर्तमान में ऐसा करने के लिए हमारे पास कोई ठोस योजना नहीं है, लेकिन हमें आपके प्रयोग के परिणाम

मैं /dist/bin/ आउटपुट पर ILRepack का उपयोग करके और System.Core.dll सहित उनमें से अधिकांश को एक साथ मिलाने में सक्षम था। अधिकांश पुस्तकालयों के संयोजन के बाद स्टार्टअप समय में सुधार किया गया था, लेकिन इसने बहुत सारे सिर खुजाने वाले बग पेश किए जिन्हें मुझे नहीं पता कि कैसे हल किया जाए; और निश्चित रूप से आप पूरे ब्लॉब को फिर से डाउनलोड किए बिना कोड के अद्यतन टुकड़ों के लिए कैशिंग पर भरोसा करने की क्षमता खो रहे हैं।

तो क्या इस पर या कम से कम ईटीए पर कोई विकास हुआ है? सर्वर-साइड काफी अच्छी तरह से काम कर रहा है लेकिन क्लाइंट-साइड WASM प्रदर्शन दुभाषिया के माध्यम से अभी भी अस्वीकार्य है जैसे ही DOM यथोचित रूप से जटिल हो जाता है।

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

इस बीच कुछ चीजें हैं जो आप वहां दर्द को कम करने के लिए कर सकते हैं, अर्थात् वर्चुअल डोम का उपयोग करना और/या सीधे RenderTreeBuilder का उपयोग करना ताकि आप सब कुछ एक ही बार में प्रस्तुत नहीं कर रहे हों और जो कुछ हो रहा है उस पर कुछ नियंत्रण हो।

खैर, मैं यह भी सोच रहा था कि क्या कुछ महीने पहले .NET 5 के बारे में घोषणा के आलोक में कुछ बदल गया है। वहां दिलचस्प उद्धरण:

Blazor परियोजना पहले से ही मोनो AOT का उपयोग कर रही है। यह .NET 5 में परिवर्तित होने वाली पहली परियोजनाओं में से एक होगी। हम इस योजना को साबित करने के लिए इसे एक परिदृश्य के रूप में उपयोग कर रहे हैं।

क्या वे कुछ ऐसा जानते हैं जो हम नहीं जानते?

इस बीच कुछ चीजें हैं जो आप वहां दर्द को कम करने के लिए कर सकते हैं, अर्थात् वर्चुअल डोम का उपयोग करना और/या सीधे RenderTreeBuilder का उपयोग करना ताकि आप सब कुछ एक ही बार में प्रस्तुत नहीं कर रहे हों और जो कुछ हो रहा है उस पर कुछ नियंत्रण हो।

वास्तव में। मैं डब्ल्यूपीएफ से प्रेरित स्क्रैच से एक एमवीवीएम ढांचा बना रहा हूं और पहली चीजों में से एक है जो ब्लेज़र के स्वचालित रेंडर ट्रिगर्स को बंद करने के लिए ShouldRender को ओवरराइड करता है और इसके बजाय पुन: प्रस्तुत करने के लिए घटकों को बताने के लिए संपत्ति परिवर्तनों पर भरोसा करता है। वास्तव में एक HUUUUGGGE प्रदर्शन सुधार, जब भी संभव हो, StateHasChanged बजाय JS इंटरऑप के माध्यम से शैलियों को अपडेट करके आता है।

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

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

SyncFusion में कुछ वर्चुअलाइजेशन घटक हैं, अर्थात् एक सूची दृश्य - पता नहीं वे कैसे काम करते हैं लेकिन मैं उनका उपयोग कर रहा हूं। शायद उन्हें जांचना चाहें।

https://github.com/SamProf/BlazorVirtualScrolling भी है जो देखने लायक भी है।

अरे हाँ मैंने देखा। यह जानकर खुशी हुई कि यह आपके लिए अच्छा काम करता है। इसमें एक समान वस्तु की ऊँचाई की आवश्यकता की महत्वपूर्ण सीमाएँ हैं और यह कि ऊँचाई पहले से ज्ञात हो। लेकिन यह एक अंतरिम समाधान हो सकता है।

क्या कोई इस मुद्दे को ब्लेज़र-वासम टैग से टैग कर सकता है? सभी सर्वर साइड (या अज्ञेयवादी होस्टिंग) ब्लेज़र मुद्दों के बीच इस मुद्दे को खोजना मुश्किल है।

और उन लोगों के लिए जो मोनो WASM AOT कार्य के लिए एक सिंहावलोकन की तलाश कर रहे हैं, मुझे यह लिंक मिला:
https://github.com/mono/mono/projects/11

आपकी इच्छा ही मेरी आज्ञा है

धन्यवाद यह बहुत मददगार है!

क्या यह संभव है कि जब हम ब्लेज़र के साथ एओटी संकलित डब्ल्यूएएसएम का प्रयोग शुरू करने में सक्षम हों, यहां तक ​​​​कि प्रयोगात्मक रूप से अनुमानों का सबसे अस्पष्ट भी प्राप्त करें? 6 महीने? एक साल? क्या ब्लेज़र टीम में किसी ने वास्तव में इसे एड-हॉक फैशन में भी सफलतापूर्वक काम किया है?

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

मैंने इस प्रश्न को यहां https://github.com/mono/mono/issues/10222 पोस्ट किया है, लेकिन उत्तर मिला कि यह गलत जगह है। यहां दोबारा पोस्टिंग:

यह घोषणा की गई थी कि Blazor WASM मई 2020 में जारी किया जाएगा। क्या हम मान सकते हैं कि यह इस समय मूल WASM एप्लिकेशन होगा? सही उत्तर क्या है?

1. हां।
2. हम कोशिश करेंगे, लेकिन हमें यकीन नहीं है।
3. नहीं, यह नवंबर 2020 में .NET 5.0 के साथ उपलब्ध होगा।
4. नहीं, और हमारे पास अभी कोई रोडमैप नहीं है।

सभी Blazor प्रशंसकों के लिए दो चीजें बहुत महत्वपूर्ण हैं:

• रनटाइम गति - दुभाषिया कुछ उपयोग के मामलों में धीमा है।
• डाउनलोड आकार - उम्मीद है कि आप वर्तमान .NET DLL के समान WASM आकार प्राप्त करने में सक्षम होंगे और हम mono.wasm को पूरी तरह से हटाने में सक्षम होंगे (मेरा मानना ​​​​है कि इस फ़ाइल में केवल IL दुभाषिया है - क्या मैं सही हूँ?)

मैं शुरू से ही ब्लेजर का बहुत बड़ा प्रशंसक हूं। मुझे पता है कि कुछ लोगों के लिए Blazor सर्वर साइड के कुछ फायदे हैं लेकिन हम सभी वास्तविक क्रांति की प्रतीक्षा कर रहे हैं - ब्राउज़र में तेज़ और विश्वसनीय Blazor।

आपकी कड़ी मेहनत के लिए धन्यवाद दोस्तों !!!

@ Andrzej-W यह किसी के लिए भी थोड़ा भ्रामक हो सकता है जो इसके माध्यम से स्किम करता है और मानता है कि नवंबर 2020 विहित रिलीज है।

व्यक्तिगत रूप से मैंने सुना है कि यह 2020 की पहली तिमाही के आसपास आधिकारिक तौर पर सामने आने वाला है।

जहां तक ​​मुझे पता है कि फूला हुआ निष्पादन योग्य आकार से परे है और तथ्य यह है कि यह अभी तक Microsoft द्वारा समर्थित नहीं है, तब तक हमें इसे अपनी निर्माण प्रक्रियाओं में लागू करने से कोई रोक नहीं सकता है।

जहां तक ​​मुझे पता है कि फूला हुआ निष्पादन योग्य आकार से परे है और तथ्य यह है कि यह अभी तक Microsoft द्वारा समर्थित नहीं है, तब तक हमें इसे अपनी निर्माण प्रक्रियाओं में लागू करने से कोई रोक नहीं सकता है।

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

.NET Conf में हमने घोषणा की कि Blazor WebAssembly की पहली रिलीज़ मई 2020 के लिए योजनाबद्ध है। इस पहली Blazor WebAssembly रिलीज़ के लिए हम उम्मीद करते हैं कि रनटाइम अभी भी IL इंटरप्रेटर पर आधारित होगा जिसका हम वर्तमान में उपयोग कर रहे हैं।

.NET रनटाइम टीम सीधे WASM को संकलित करने के लिए समय से पहले संकलन समर्थन पर काम कर रही है। इस दृष्टिकोण में रनटाइम प्रदर्शन में सुधार करने का लाभ है, लेकिन ऐप आकार की कीमत पर।

मई में Blazor WebAssembly की प्रारंभिक रिलीज़ के लिए हम मिश्रित मोड में IL दुभाषिया चलाने की खोज कर रहे हैं, जहाँ हॉट पाथ को WASM के लिए संकलित किया गया है, लेकिन बाकी ऐप .NET असेंबली हैं। यह रनटाइम प्रदर्शन और ऐप आकार के बीच एक अच्छा समझौता प्रदान करता है। हालाँकि, यह अभी तक स्पष्ट नहीं है कि यह मई के लिए समय पर उतरेगा या नहीं।

लंबे समय तक, हम एक ऐसा SDK प्रदान करना चाहते हैं जो ऐप डेवलपर को यह नियंत्रित करे कि उनके ऐप के कौन से हिस्से सीधे WASM में संकलित किए गए हैं। ऐसा एसडीके कब उपलब्ध होगा, इसका अभी कोई रोडमैप नहीं है।

@lewing @richlander

स्पष्टीकरण के लिए @ danroth27 धन्यवाद। डाउनलोड आकार को सर्वर साइड प्रीरेंडरिंग द्वारा आंशिक रूप से छुपाया जा सकता है - सुनिश्चित करें कि यह https://github.com/danroth27/ClientSideBlazorWithPrerendering भविष्य के सभी ब्लेज़र (प्री) रिलीज़ में काम करेगा।

@ danroth27 अद्यतन के लिए धन्यवाद! एक स्पष्टीकरण प्रश्न - क्या ".NET रनटाइम टीम" मोनो टीम, CoreRT, .NET 5, या कुछ और को संदर्भित करता है?

@legistek वे सभी अब एक टीम हैं: मुस्कान:। तकनीक हालांकि मोनो रनटाइम पर आधारित है।

ओह, ठीक है मैं भूल गया। ;डी मुझे जो मिल रहा था वह यह था कि क्या इस विषय पर जानकारी के लिए मोनो/वासम/10222 सही मुद्दा/रेपो था।

@legistek हाँ, सभी .NET WASM वर्तमान में मोनो रेपो में काम कर रहे हैं।

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

मैं वास्तव में यह जानने के लिए मर रहा हूं कि यह संकलित WASM के साथ कैसे चलेगा।

अगर हम कुछ समय के लिए डाउनलोड आकार या संकलन समय को अनदेखा करते हैं, तो क्या एओटी द्वारा ब्लेज़र ऐप को डब्ल्यूएएसएम में संकलित करने और इसे आज़माने का कोई तरीका है? मोनो रेपो (https://github.com/mono/mono/issues/10222) पर लोग AOT के कुछ उदाहरण Uno जैसे अन्य प्लेटफॉर्म के साथ पोस्ट कर रहे हैं, लेकिन मुझे अभी तक एक Blazor उदाहरण देखना है, अकेले निर्देश दें कि कैसे इसे करने के लिए।

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

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

@legistek क्या आपने अपना ऐप या कुछ और बनाया है? प्रदर्शन कितना बेहतर है? क्या आपके पास साझा करने के लिए कुछ मीट्रिक हैं? उत्सुकतावश पूछ रहे हैं।

मैंने अपने ऐप का एक सबसेट बनाया और फिर कुछ प्रदर्शन मेट्रिक्स चलाए क्योंकि मैं ब्लेज़र बूटस्ट्रैपिंग के बिना पूरी चीज नहीं चला सका।

गणित के लिए (यादृच्छिक संख्या पीढ़ी और सरल अंकगणित) मैंने एओटी को व्याख्या की तुलना में लगभग 40x तेज पाया।

जिन चीजों में मुझे वास्तव में दिलचस्पी थी, वे चीजें थीं जिन्हें मैं जानता था कि प्रतिबिंब और स्ट्रिंग मैनिपुलेशन जैसे अक्षम होंगे। मेरे ऐप में डब्ल्यूपीएफ के समान एक कस्टम डेटा बाध्यकारी ढांचा है इसलिए मैंने एक जटिल डेटा बाध्यकारी स्थापित करने और मान को 10,000 बार यादृच्छिक स्ट्रिंग में बदलने का प्रयास किया। यहाँ परिणाम थे:

मोनो इंटरप्रेटेड आईएल: 2.49s
पूर्ण एओटी (क्रोम): 0.702s
पूर्ण एओटी (फ़ायरफ़ॉक्स): 0.5s
मूल निवासी: 0.067s

तो मूल रूप से हमारे पास एओटी की सबसे खराब स्थिति है जो व्याख्या किए गए आईएल के रूप में लगभग 4x तेज है, लेकिन 40x जितना अच्छा मामला परिदृश्य है।

मुझे लगता है कि शायद इसकी उम्मीद की जानी चाहिए।

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

मुझे लगता है कि निकट भविष्य में प्रदर्शन में उल्लेखनीय सुधार होगा क्योंकि ब्राउज़र विक्रेता WebAssembly को अधिक गंभीरता से लेना शुरू कर देंगे।

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

https://d07riv.github.io/diabloweb/ जैसी परियोजनाएं बिना किसी संदेह के साबित करती हैं कि WebAssembly खुद को संभालने में सक्षम से अधिक है लेकिन मुझे अभी तक Mono+WASM पर चलने वाली अवधारणा का एक समान प्रभावशाली प्रमाण देखना बाकी है।

यह मुद्दा दो साल के लिए खुला है.. क्या कोई प्रगति हुई है?

@पार्टीलाइट हां, प्रगति हुई है। https://github.com/mono/mono repo में WASM के लिए AoT संकलन का कार्यान्वयन है और .NET IL और संकलित WASM फ़ाइलों के मिश्रण को निष्पादित करने में सहायता के लिए रनटाइम को अपडेट किया गया है। हालाँकि, AoT सपोर्ट आगामी मई रिलीज़ के लिए तैयार नहीं होगा। हम इसे .NET 5 के लिए शिपिंग पर फिर से देखेंगे।

मैंने एओटी संकलन विकल्प की कोशिश की डैन का जिक्र है और यह यूनो के साथ अच्छी तरह से काम करता है।

मैं अभी भी इस बारे में अपना सिर खुजला रहा हूं कि अभी तक इसका कम से कम एक PoC ब्लेज़र के साथ काम क्यों नहीं कर रहा है? मुझे एहसास है कि टूलचेन अभी भी लिनक्स है और आउटपुट फाइलें अंततः हम जितना चाहते हैं उससे कहीं अधिक बड़ी हैं, लेकिन एओटी के साथ काम करने वाले ब्लेज़र ऐप का उदाहरण बनाने से क्या रोक रहा है ताकि हम प्रदर्शन और व्यवहार्यता का आकलन कर सकें?

मुझे यकीन नहीं है कि यह संबंधित है, लेकिन सिंकफ्यूजन रिपोजिटरी पर कुछ समय पहले एक प्रदर्शन समस्या की सूचना दी गई थी (https://github.com/syncfusion/blazor-samples/issues/50), जिसके कारण कहा जाता है मोनो का धीमा प्रदर्शन।

मेरे विश्लेषण में, प्रदर्शन समस्या js_to_wasm पर कॉल करने के लिए कम हो जाती है:

क्या यह कुछ ऐसा है जिसे इस और मोनो टीम द्वारा हल किया जाएगा? या यह कुछ असंबंधित है?

@Herdo यह इससे संबंधित हो सकता है: https://github.com/dotnet/aspnetcore/issues/5617

यह देखने के लिए अपने वेब कंसोल लॉग की जाँच करें कि क्या यह अत्यधिक GCing है। ऐसा लगता है कि इसे WASM मोनो रनटाइम में बेक किया गया है और इसे कॉन्फ़िगर करने योग्य IMO होना चाहिए।

@honkmother ,
क्या आप कृपया अधिक जानकारी साझा कर सकते हैं कि आप ब्लेज़र डीएलएल को ILRepack के साथ पैकेजिंग करने में कैसे सफल हुए? मैंने यहां विस्तृत विवरण के अनुसार ILRepack.MSBuild.Task का उपयोग किया

WASM: System.IO.FileNotFoundException: फ़ाइल या असेंबली 'नेटस्टैंडर्ड, वर्जन = 2.1.0.0, कल्चर = न्यूट्रल, पब्लिककीटोकन = cc7b13ffcd2ddd51' या इसकी किसी एक निर्भरता को लोड नहीं कर सका।

ऐसा प्रतीत होता है कि पैकेजिंग कुछ तोड़ती है, या सूची में एप्लिकेशन के सही बूटस्ट्रैप को रोकता है।

हम्म AOT, UNO में है . क्या आप इस समाधान को सी एंड पी कर सकते हैं?

.नेट 5 ब्लेज़र के लिए एओटी संकलन का समर्थन नहीं करेगा?

यह रोडमैप से भी हट गया है।

मैं निष्कर्ष पर पहुंचने से पहले आधिकारिक टिप्पणी सुनना चाहता हूं, लेकिन अगर यह सच है तो यह बहुत बुरी खबर है जो न केवल ब्लेज़र को प्रभावित करती है बल्कि मुझे .NET को एक फ्रंटएंड प्लेटफॉर्म के रूप में पुनर्मूल्यांकन करने के लिए मजबूर करती है।

इसके मोनो पक्ष पर महीनों में कोई रिपोर्ट नहीं की गई है:
https://github.com/mono/mono/issues/10222

हो सकता है कि यह घाटे में कटौती करने और इसके बजाय CoreRT पर ध्यान केंद्रित करने का समय हो।

@ ram16g @legistek हम .NET 5 (और उससे आगे) में Blazor WebAssembly रनटाइम प्रदर्शन को

नमस्ते @ danroth27 , समग्र प्रदर्शन अभी मेरी चिंता के लिए इतना अधिक नहीं है, लेकिन प्रारंभिक स्टार्टअप प्रदर्शन के बारे में क्या है? वास्तविक पृष्ठ लोड होने तक प्रत्येक पृष्ठ पर जाने में 2-3 सेकंड लगते हैं, जब तक कि रनटाइम लोड नहीं हो जाता है, संकलित डीएलएल आदि। क्या एओटी के बिना सुधार होगा? या क्या हमें प्रीरेंडरिंग पर भरोसा करने की ज़रूरत है?

हाय @MichaelPeter। प्रारंभिक पृष्ठ लोड समय ऐप डाउनलोड करने और रनटाइम शुरू करने पर हावी है। AoT वास्तव में इसमें मदद नहीं करेगा। AoT का उद्देश्य रनटाइम प्रदर्शन में सुधार करना है, न कि ऐप डाउनलोड आकार को कम करना। JIT आधारित रनटाइम के लिए AoT स्टार्टअप प्रदर्शन में सुधार कर सकता है क्योंकि आप रनटाइम पर JIT की आवश्यकता से बचते हैं, लेकिन Blazor WebAssembly बिना किसी JIT समर्थन के IL दुभाषिया आधारित रनटाइम का उपयोग करता है।

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

ऐप स्टार्टअप प्रदर्शन को बेहतर बनाने के लिए हम .NET IL लिंकर में और सुधार कर रहे हैं और कोर फ्रेमवर्क लाइब्रेरी को और अधिक लिंक करने योग्य बनाने के लिए काम कर रहे हैं। डाउनलोड होने के बाद हम रनटाइम के स्टार्टअप प्रदर्शन को देखने की भी योजना बना रहे हैं।

@ danroth27 क्या ऐप स्टार्टअप प्रदर्शन की प्रगति के बारे में कोई समस्या है जिसका मैं अनुसरण कर सकता हूं? ब्लेज़र को लेकर इस समय मेरी सबसे बड़ी चिंता यही है।

@ danroth27 : +1: जानकारी के लिए बहुत बहुत धन्यवाद, मैं ज्यादातर लैन envoirements में Blazor का उपयोग करता हूं जहां डाउनलोड समय लगभग शून्य होना चाहिए और सोचा कि ब्राउज़र कैशिंग कर रहा है। नेट डीएलएल वैसे भी। लेकिन स्टार्टअप इश्यू में मुझे भी बहुत दिलचस्पी होगी।

कृपया ध्यान दें कि ब्लेज़र दुभाषिया जैसे WebAssembly-आधारित अनुप्रयोगों के लिए स्टार्टअप समय इस बात पर निर्भर हो सकता है कि ब्राउज़र फ़ाइलों को ठीक से कैश कर रहा है या नहीं। यदि आपके एप्लिकेशन को होस्ट करने वाला वेब-सर्वर गलत तरीके से कॉन्फ़िगर किया गया है या फ़ाइल बदल गई है या ब्राउज़र अन्यथा एप्लिकेशन को कैश करने में असमर्थ है, तो इसे हर बार ऐप शुरू करने पर इसे फिर से शुरू करना होगा। आदर्श परिस्थितियों में, ब्राउज़र इसे कैश करने में सक्षम होता है, इसलिए आपकी पहली विज़िट के बाद भविष्य में विज़िट बहुत तेज़ी से शुरू होंगी।

इस बारे में जानकारी के लिए आप https://v8.dev/blog/wasm-code-caching देख सकते हैं। फ़ायरफ़ॉक्स में एक समान तंत्र है, और मेरा मानना ​​​​है कि सफारी भी करता है लेकिन मैं निश्चित नहीं हूं।

@ danroth27 मैं वास्तव में स्पष्टीकरण और उस स्थिति की सराहना करता हूं जिसमें आप .NET 5 को अन्य सभी चीजों के साथ तैयार करने की कोशिश कर रहे हैं। कुछ टिप्पणियाँ/प्रश्न:

AoT के लिए पहला कदम है Blazor WebAssembly को उसी कोर .NET पुस्तकालयों का उपयोग करने के लिए स्थानांतरित करना जो .NET कोर द्वारा उपयोग किए जाते हैं, जो प्रदर्शन में भी मदद करनी चाहिए

मुझे लगता है कि आप मोनो mscorlib से CoreFX पर स्विच करने की बात कर रहे हैं? मुझे लगता है कि यह एक उत्कृष्ट कदम है यदि ऐसा कई प्रकाशित प्रदर्शन बेंचमार्क को देखते हुए कोरएफएक्स को मोनो (और उस मामले के लिए नेटएफएक्स) से बेहतर प्रदर्शन करते हुए दिखाया गया है।

फिर हमें यह पता लगाने की जरूरत है कि आईएल लिंकिंग के साथ एओटी को कैसे अच्छी तरह से काम करना है।

हाँ लिंकिंग कुछ समय के लिए एक बड़ी बाधा रही है जैसा कि यहाँ चर्चा की गई

डाउनलोड होने के बाद हम रनटाइम के स्टार्टअप प्रदर्शन को देखने की भी योजना बना रहे हैं।

इसके DOM बिल्डिंग पीस को भी ध्यान से देखने की जरूरत है। एक खाली Blazor ऐप को लोड करने में मेरे डेस्कटॉप पर 1-2 सेकंड और मोबाइल पर कुछ और समय लगता है। कोणीय दुनिया में रहने के बाद मुझे हर बार "लोड हो रहा है ..." देखने की आदत है और आधार स्टार्टअप समय ठीक लगता है। बड़ी समस्या जटिल DOMs का निर्माण करने वाली कष्टदायी धीमी गति है। यहां तक ​​​​कि 1000-2000 तत्वों वाले डोम भी प्रारंभिक लोड के लिए 5-10 सेकंड तक जोड़ते हैं, और जटिल वस्तुओं से जुड़ी अंतःक्रियाशीलता भी महत्वपूर्ण अंतराल जोड़ती है। मुझे नहीं लगता कि इस बारे में ज्यादा बात हो रही है और मुझे चिंता है कि (1) एओटी इसे हल नहीं करेगा क्योंकि यह डब्ल्यूएएसएम/जेएस इंटरऑप के लिए स्थानिक है और जिस तरह से दोनों के बीच तारों का आदान-प्रदान किया जाता है; और (२) ब्लेज़र में रेंडरिंग/डिफिंग मैकेनिज्म अब इतना बेक हो गया है कि इसे किसी ऐसी चीज़ में बदलने में बहुत देर हो चुकी है जो उच्च प्रदर्शन वाली होगी।

वर्तमान सोच यह है कि हम एओटी टूलचेन को डेवलपर्स के लिए उपलब्ध कराएंगे ताकि आप यह तय कर सकें कि आप अपने ऐप को कितना एओटी करना चाहते हैं और फिर ऐप मिश्रित मोड में चलेगा,

ठीक वैसे ही जैसे Uno पहले से कर रहा है...

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

एसपीए के कार्यभार संभालने के बाद से .NET ने एक फ्रंटएंड वेब प्लेटफॉर्म के रूप में इतना आधार खो दिया है और क्रोम प्रतिबंध लगाने वाले प्लगइन्स के लिए सिल्वरलाइट की मृत्यु हो गई है। ब्लेज़र वह सब बदल सकता था। लेकिन मैं अभी यह नहीं बता सकता कि क्या Blazor WASM वास्तव में Microsoft द्वारा रणनीतिक गेम चेंजर के रूप में अभिप्रेत है या यह मेरे जैसे फैनबॉय के लिए सिर्फ एक जिज्ञासा हो सकती है। लेकिन फैनबॉय या नहीं, एक व्यवसाय के स्वामी के रूप में अगर मैं आज एक नई परियोजना के लिए एक फ्रंटएंड फ्रेमवर्क चुन रहा हूं या एक पुराने के पुनर्निर्माण के लिए, मैं अपने समर्थकों को कैसे उचित ठहरा सकता हूं कि ब्लेज़र जाने का रास्ता है, रिएक्ट या एंगुलर पर? जब मैं पेशेवरों और विपक्षों को सूचीबद्ध करता हूं, तो मुझे सी # पसंद करने के अलावा एक समर्थक के रूप में क्या बचा है? दूसरी ओर, विपक्ष बढ़ते रहते हैं।

इसलिए मैं बहुत निराश और थोड़ा निराश हूं। यह केवल लंबे समय तक इंतजार नहीं करना है, यह है कि अभी भी कई संदेह हैं कि क्या यह तकनीक कभी व्यवहार्य होगी, और मैं एक के लिए एओटी को देखने का इंतजार कर रहा था ताकि मैं यह दृढ़ संकल्प कर सकूं।

मैं यह उम्मीद नहीं कर रहा हूं कि आप लोग अपना रोडमैप बदल दें या वास्तव में आज इनमें से किसी भी चिंता को दूर करने की स्थिति में हों, लेकिन मुझे लगा कि वे प्रसारित होने लायक हैं। मैं बेहद चाहता हूं कि यह सफल हो और इंटरेक्टिव वेब ऐप्स के राजा के रूप में अपनी जगह को पुनः प्राप्त करने के लिए .NET के अलावा और कुछ नहीं पसंद करेगा। लेकिन अगर मुझे आज इस पर पैसा लगाना पड़ा, तो यह एक अच्छा दांव नहीं लग रहा है। कृपया मुझे गलत साबित करें!

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

@ danroth27 ब्लेज़र के लिए JSON अक्रमांकन की गति वस्तुओं की बड़ी सूचियों के लिए बेहद धीमी है, क्या वर्तमान में धीमी दुभाषिया तरीके का उपयोग करने के बजाय इसे तेजी से करने के बारे में कोई मार्गदर्शन है।

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

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

स्टार्टअप समय कम करने के लिए, मैं आलसी लोडिंग का सुझाव देता हूं। मतलब केवल वही dll लोड करें जो उस विशिष्ट दृश्य या पृष्ठ के लिए आवश्यक हों। यह वास्तव में स्टार्टअप को गति देगा

@ ram16g @legistek हम .NET 5 (और उससे आगे) में Blazor WebAssembly रनटाइम प्रदर्शन को

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

@hoksource हमारे पास सटीक संख्या नहीं है कि कैसे perf विशेषताएँ बदल जाएँगी, हालाँकि यदि आप 1-2 महीनों में पूर्वावलोकन आज़माते हैं तो आपको पता चल जाएगा।

@hoksource हमारे पास सटीक संख्या नहीं है कि कैसे perf विशेषताएँ बदल जाएँगी, हालाँकि यदि आप 1-2 महीनों में पूर्वावलोकन आज़माते हैं तो आपको पता चल जाएगा।

@SteveSandersonMS ठीक है तो
मेरा लक्ष्य योगदान करने के लिए निम्नलिखित करने में सक्षम होना होगा:

विकल्प 1: प्रत्यक्ष दृष्टिकोण (समस्या से सीधे निपटना):
[] मोनो प्रोजेक्ट को संकलित करना सीखें
[ ] asp.net ब्लेज़र प्रोजेक्ट को संकलित करना सीखें
[ ] webassembly के साथ asp.net ब्लेज़र को संकलित करना सीखें
[ ] ब्लेज़र क्लाइंट प्रोग्राम को पूरी तरह से वेब असेंबली में संकलित करना सीखें (क्या मोनो-> वेबअसेंबली एओटी किया गया है? क्या यह सभी संदर्भ बायनेरिज़ को 1 wasm फ़ाइल में जोड़ सकता है?)
[ ] जांचें कि मोनो वेब असेंबली के लिए एक संपूर्ण वेब असेंबली प्रोजेक्ट संकलित कर सकता है या नहीं।
[ ] वेब असेंबली में सभी अनुपलब्ध c#/.net भाषा का समर्थन करने का तरीका जानें
[] सभी dll को 1 wasm या एकाधिक wasm फ़ाइलों में बदलने के लिए इष्टतम लिंकिंग संरचना का पता लगाएं
[ ] फ़ाइल आकार और प्रदर्शन को तौलने से ऊपर करने का सबसे अच्छा तरीका पता करें
[ ] बाइनरी को 1 वेब असेंबली से जोड़ना और मर्ज करना सीखना/डिज़ाइन करना या आंशिक असेंबली के साथ आलसी लोड करने की अनुमति देना
[ ] समाधान के विभिन्न सेट हैं, शीर्ष कुछ सर्वोत्तम समाधान चुनें, उन्हें आप लोगों के सामने प्रस्तुत करें। वर्तमान परियोजना से कुछ सार्वजनिक/निजी भंडार शाखा के माध्यम से

विकल्प 2: (समस्या से अप्रत्यक्ष रूप से निपटें)
[ ] मैं छोटे/आसान मॉड्यूल/डिजाइनिंग/दस्तावेजों जैसे छोटे छोटे सरल कार्य करूंगा, विश्वास है कि अधिक से अधिक इंजीनियर/डिजाइनर अपने संसाधनों को nov .net 5 रिलीज से पहले विकल्प 1 पर बताए गए प्रत्यक्ष दृष्टिकोण पर केंद्रित/निर्देशित कर सकते हैं।

• अतिरिक्त प्रश्न। क्या सभी संदर्भ पुस्तकालयों को खुला स्रोत माना जाता है? मेरे पास कुछ पुस्तकालय कोड हैं, लेकिन मुझे यकीन नहीं है कि मैं उन सभी को सार्वजनिक रूप से बेनकाब करना चाहता हूं।

लेकिन मुझे लगता है कि विकल्प 1 सबसे अच्छा विकल्प होगा क्योंकि मैं कुछ अन्य चीजों को दोबारा नहीं करूँगा जो आप में से एक कर रहे हैं। कृपया पुष्टि करें कि क्या मैंने कुछ याद किया है।

@hoksource शामिल होने की आपकी इच्छा के लिए धन्यवाद। वर्तमान में एकमात्र व्यावहारिक विकल्प विकल्प 1 है, क्योंकि ASP.NET कोर टीम अन्य कार्यों में पूरी तरह से व्यस्त है। मुझे पता है कि आपको बड़ी संख्या में चीजों का पता लगाना होगा, लेकिन उम्मीद है कि यह समझाने में मदद करता है कि यह ऐसा कुछ क्यों नहीं है जिसे हम सिर्फ .NET 5 मील के पत्थर में खिसकने में सक्षम हैं :) ऐसा लगता है कि आपके पास अच्छी अंतर्दृष्टि है यहां आवश्यक चीजों की श्रेणी में।

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

यह पूरी तरह आप पर निर्भर करता है कि आप ओपन सोर्स क्या बनाते हैं और क्या नहीं। ASP.NET Core अपने आप में खुला स्रोत है, लेकिन आप चाहें तो इसके ऊपर क्लोज्ड-सोर्स चीजें बना सकते हैं। हम यहां अपने रेपो में केवल ओपन सोर्स चीजें शामिल कर सकते हैं।

JIT आधारित रनटाइम के लिए AoT स्टार्टअप प्रदर्शन में सुधार कर सकता है क्योंकि आप रनटाइम पर JIT की आवश्यकता से बचते हैं, लेकिन Blazor WebAssembly बिना किसी JIT समर्थन के IL दुभाषिया आधारित रनटाइम का उपयोग करता है।

जिज्ञासा से बाहर: क्या क्लाइंट पर JITting पूर्ण AoT की व्याख्या/जाने का एक व्यावहारिक विकल्प होगा?

हाय दोस्तों! बस कुछ टीमों और चीजों के साथ बात कर रहा था। ऐसा लगता है कि स्कीशर्प जैसे पुस्तकालयों के लिए यह काफी जरूरी है। SkiaSharp का मुख्य भाग एक मूल पुस्तकालय है और आउटपुट मूल रूप से एक .a फ़ाइल है जिसे स्थिर रूप से लिंक करने की आवश्यकता है। हम संभावित रूप से एक गतिशील देशी पुस्तकालय का निर्माण कर सकते हैं, लेकिन क्या Blazor इसका समर्थन भी करता है?

एफवाईआई, वर्तमान में मूल पुस्तकालय को रनटाइम में स्थिर करना संभव है। यह ऐसा कुछ नहीं है जिसे मैं अनुशंसा करता हूं क्योंकि यह गैर-तुच्छ है, लेकिन आप ऐसा कर सकते हैं और फिर सभी टुकड़े होने के बाद स्थिर रूप से जुड़े पुस्तकालय में पी/आमंत्रण कर सकते हैं। मुझे नहीं पता कि हमारे पास कोई परीक्षण मामले हैं जो इसे अभी तक करते हैं, इसलिए इसके लिए कुछ अतिरिक्त बुनियादी ढांचे की आवश्यकता हो सकती है जो अभी तक ब्लेज़र में शिपिंग नहीं कर रहे हैं। आपको अपने ब्लेज़र बिल्ड के साथ एकीकृत करने के लिए अपने स्वयं के dotnet.wasm/dotnet.js को संकलित करना होगा जो दिल के बेहोश होने के लिए नहीं है।

गतिशील देशी पुस्तकालय एक और मामला है, मेरी समझ यह है कि सामान्य रूप से उसके लिए टूलिंग सामान्य रूप से महान नहीं है, इससे पहले कि आप इस सवाल पर भी पहुंचें कि ब्लेज़र उनका समर्थन करता है या नहीं।

मुझे पिछले साल पता चला कि इस समय डायनेमिक लिंकिंग एक व्यवहार्य समाधान नहीं है। एम्सस्क्रिप्टन का तात्पर्य है कि "मुख्य" wasm मॉड्यूल में सिस्टम लाइब्रेरी के सभी संभावित संयोजन शामिल हैं, कोई भी गतिशील पुस्तकालय उपयोग करना चाहेगा। यह शुरू करने के लिए एक बहुत बड़े सामान्य wasm मॉड्यूल के लिए बनाता है।

मैंने थोड़ी देर के लिए Uno.SkiaSharp के साथ उस दृष्टिकोण का उपयोग करने की कोशिश की, लेकिन यह मोटा था और इसे एक तरफ रख दिया (जिस बिंदु पर @vargaz ने शायद खुद को "आपको ऐसा बताया" कहने से परहेज किया था)।

Uno बूटस्ट्रैपर अब विंडोज़ पर स्टैटिक लिंकिंग (दिशाएँ यहाँ ) और P/Invoke का उपयोग WSL के माध्यम से करने में सक्षम है, और चूंकि यह उसी निष्पादन पथ का उपयोग कर रहा है जो आंतरिक System.Native इंटरऑप उपयोग करता है, यह अब बहुत स्थिर है। तुम भी इस तरह जंग मॉड्यूल के साथ आसानी से इंटरऑप कर सकते हैं।

मैंने कुछ पढ़ा, केवल .net रनटाइम को wasm में बदल दिया गया। स्टार्टअप पर सभी डीएलएस डाउनलोड और पार्स किए जाते हैं। ऐसा लगता है कि इस्तेमाल किया जा रहा wasm रनटाइम मोनो है। उनका लक्ष्य अब इसके बजाय .net कोर रनटाइम का उपयोग करना है।

वर्तमान पूर्ण एओटी कंपाइलर मोनो द्वारा किया जा रहा है, लेकिन मुझे यकीन नहीं है कि नेट कोर के साथ एक पूर्ण एओटी पथ/मार्ग होना चाहिए। (पता नहीं मैं यहां क्या कह रहा हूं। विशेषज्ञ की जरूरत है)

इंटरनेट का कहना है कि कम्प्यूटेशनल गहन कार्यों के लिए .net कोर मोनो की तुलना में दोगुना तेज चलता है। स्टार्टअप io संबंधित है, पहला .dll बायनेरिज़ और निर्भरता डाउनलोड कर रहा है। (एकाधिक फाइलें) उन्हें स्मृति में पार्स करना। फिर उसके ऊपर ब्लेज़र wasm क्लाइंट ऐप शुरू करें। डाउनलोडिंग में कुछ समय लगता है (लेकिन कैश किया जा सकता है) और पार्सिंग में कुछ समय लगता है। एओटी कंपाइलर यह भी नहीं जानता है कि ब्लेज़र की निर्भरता कौन सी है और कौन सी ऐप विशिष्ट है। यदि आप हमेशा सेट करते हैं कि कौन सा dll aot wasm में शामिल करना है तो यह गड़बड़ हो जाएगा। तो एक पूर्ण आट अच्छा लगता है। (लेकिन यह मोनो के बजाय .net कोर रनटाइम कार्यान्वयन के साथ तेज़ होगा? इस बारे में फिर से निश्चित नहीं है) मुझे यह भी यकीन नहीं है कि पूर्ण एओटी वासम संकलन का डिज़ाइन/कार्यान्वयन मोनो या .नेट रनटाइम के साथ किया जाता है। प्रगति के बारे में भी निश्चित नहीं है

@ danroth27 क्या कोई प्रगति हुई है?

क्या यह .NET 5 में उपलब्ध होगा?
इस कार्यक्षमता को भी जांचने के लिए कुछ पूर्व-रिलीज़ होना अच्छा होगा;)

@redradist AOT .NET 5 तक नहीं होगा। वे ब्लेज़र वासम पर अनुकूलन कर रहे हैं। लेकिन मैंने जो पढ़ा है उससे वे असेंबली और फील्ड ट्रिमिंग कर रहे हैं। और रनटाइम अनुकूलन। उम्मीद है कि मोबाइल फोन पर कैश किए जाने पर उन्हें <1 स्टार्टअप मिल सकता है। danroth27 टिप्पणी

@hoksource

@redradist AOT .NET 5 तक नहीं होगा। वे ब्लेज़र वासम पर अनुकूलन कर रहे हैं। लेकिन मैंने जो पढ़ा है उससे वे असेंबली और फील्ड ट्रिमिंग कर रहे हैं। और रनटाइम अनुकूलन। उम्मीद है कि मोबाइल फोन पर कैश किए जाने पर उन्हें <1 स्टार्टअप मिल सकता है। danroth27 टिप्पणी

यह दुख की बात है :(

मेरा एक सवाल है। क्या आप Blazor AOT के साथ काम कर रहे हैं:

1. C# को सीधे WebAssembly बाइटकोड प्रारूप में संकलित करना
2. या आप .NET DLL में संकलित IL को WebAssembly बाइटकोड प्रारूप में बदलने पर काम कर रहे हैं?

दृष्टिकोण 2) सभी .NET उपकरण (हमारे सहित) को संरक्षित करेगा जो काम करने के लिए मानक आईएल और मेटाडेटा संकलित और पीडीबी पर भरोसा करते हैं। इसके अलावा 2) के पास अतिरिक्त लाभ होगा कि System DLL को WebAssembly में भी संकलित किया जाए, हो सकता है कि कोड को रनटाइम पर निष्पादित नहीं किया गया हो (देखें Mono.Linker प्रोजेक्ट @JbEvain द्वारा)।
धन्यवाद

बीटीडब्ल्यू ब्लेज़र के बारे में बहुत सारे संसाधन हैं लेकिन मुझे ब्लेज़र इंटर्नल्स के बारे में खुद को शिक्षित करने के लिए सही ग्रैन्युलैरिटी वाला नहीं मिला इसलिए मैंने इसे लिखा।

२ नहीं १

साथ ही, मुझे आशा है कि एओटी प्रक्रिया डिबगिंग को अधिक आसान बनाने के लिए उपयुक्त स्रोत मानचित्र (wasm से C# तक) उत्पन्न करेगी।

मैं .Net 6 पूर्वावलोकन रिलीज़ के लिए Q1 2021 में इस समर्थन को देखने की उम्मीद कर रहा हूं। यह वेब ब्राउज़र में मूल रूप से चल रहे स्कीयाशर्प जैसे रेपो का समर्थन करने के लिए मूलभूत है।

हमसे संपर्क करने के लिए धन्यवाद।
हम भविष्य के मूल्यांकन/विचार के लिए इस मुद्दे को Next sprint planning मील के पत्थर पर ले जा रहे हैं। जब हम अगले मील के पत्थर के लिए काम की योजना बना रहे हों तो हम अनुरोध का मूल्यांकन करेंगे। आगे क्या होने की उम्मीद है और इस मुद्दे से कैसे निपटा जाएगा, इस बारे में अधिक जानने के लिए आप हमारी ट्राइएज प्रक्रिया के बारे में यहां और अधिक पढ़ सकते हैं।