Aspnetcore: kompilasi AOT

Tindak lanjuti status mono-wasm

Apakah Anda tahu masalah di mana kami dapat melacak kemajuan dalam hal ini?

Mode juru bahasa saat ini sangat lambat.
https://dotnetfiddle.net/JUpsRT

.NET 300 mdtk
WASM: 13155 mdtk

Yup, kami pikir ini lebih merupakan hasil dari belum ada yang dioptimalkan daripada indikasi bahwa kami harus pindah ke AoT pada saat ini, tetapi kami akan tahu lebih banyak saat penerjemah IL dan dukungan AoT matang.

@ danroth27 Dari apa yang saya tahu perbedaan kinerja antara penerjemah Mono IL dan versi mono.wasm saat ini adalah sekitar 5-10x. Keseluruhan mono.wasm sekitar 50-80x dan penerjemah IL sekitar 10x lebih lambat dari aplikasi konsol .NET Core asli.

Jadi penerjemah saat ini masih tidak terlalu cepat secara keseluruhan dan WebAssembly menambahkan lebih banyak overhead di atas itu.

Saya akan berasumsi bahwa AOT mungkin masih memiliki peluang yang lebih baik untuk mempercepat, tetapi Anda benar bahwa kemungkinan besar terlalu dini untuk mengesampingkan penerjemah, karena sebagian besar aplikasi web bahkan tidak memiliki tuntutan kinerja tinggi dan kemungkinan besar akan baik-baik saja dengan versi yang ditafsirkan.

AOT menjadi lebih efisien tidak hanya penting untuk aplikasi intensif. Ini juga penting untuk seluler dan platform kelas bawah lainnya, terutama jika Anda mempertimbangkan penggunaan baterai.

Apakah saat ini ada cara yang layak untuk mengaktifkan kompilasi AoT untuk proyek Blazor? Saya terus membaca posting blog yang mengklaim Blazor sudah memiliki mode AoT; jika ini benar, dapatkah seseorang menunjukkan artikel yang menjelaskan cara mengaktifkannya?

@TheFanatr kompilasi AOT bergantung pada mono yang mendukung fitur ini. Sejauh yang saya tahu, pembaruan terakhir tentang topik itu berasal dari @migueldeicaza di Blazor Gitter .

Miguel de Icaza (2018-06-08 19:01):
Kami sedang mengerjakannya. Apa yang terjadi adalah ini:
Interpreternya menggunakan “emscripten” yang memiliki libc cukup lengkap yang bisa kita andalkan. Dan mesin AOT kami dibangun di atas LLVM murni, yang mengharuskan kami untuk menulis libc penuh. Yang terakhir adalah tempat yang ideal, karena kami mendapatkan tautan asli dan dukungan llvm langsung dan sebagainya. Tapi akan mengirim kami ke jalan harus menulis libc itu.
Jadi untuk jangka pendek, kita pindah ke emscripten compiler AOT, pastikan kita menjaga kompatibilitasnya. Kelemahannya adalah bahwa perkakas emscripten lebih tua, sehingga banyak bagian yang lebih baik seperti tautan LLVM tidak tersedia. Jadi kami sedang mengerjakan hal-hal itu.
Pada dasarnya, kami telah melakukan sesuatu, tetapi kami harus mulai dari awal untuk bekerja dengan apa yang kami miliki tanpa memaksa kami untuk menulis dan meniru semuanya sendiri. Kami bisa saja mencoba memadukan keduanya, tetapi itu juga merupakan upaya besar. Jadi kami pikir kami dapat melakukan emscripten untuk saat ini melalui beberapa peretasan yang cerdik di sana-sini.

Jadi singkatnya, mereka sedang mengerjakannya, tetapi tidak ada opsi yang baik untuk melakukan ini dengan build publik saat ini.

Beberapa kemajuan yang cukup besar baru saja dilaporkan di CoreRT !!

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

ada yang punya ide tentang apa yang memblokir ini? saya mungkin bersedia untuk dimasukkan ke dalam beberapa triliun jam kerja untuk melihat AOT terjadi lebih cepat daripada nanti sekarang blazor sisi klien telah berkomitmen oleh kekuatan yang ada di Microsoft. AOT akan menjadi sangat penting jika kita ingin mengembangkan PWA (sangat baik) dengan Blazor.

@honkmother AoT sedang dikerjakan oleh orang-orang mono.wasm di https://github.com/mono/mono repo. Saya yakin mereka akan senang mendapatkan bantuan Anda! Masalah ini melacak konsumsi pekerjaan mereka setelah siap.

Saya pikir saya memiliki pertanyaan yang agak terkait tetapi tidak dipikirkan dengan baik dan kata-kata yang buruk - Saya telah bereksperimen dengan ILRepack dan Blazor, dan berhasil mengemas sebagian besar dll menjadi satu gumpalan monolitik. Apakah kalian berniat untuk mengemas perpustakaan umum bersama-sama sebagai satu dll?

@honkmother Saat ini kami tidak memiliki rencana konkret untuk melakukannya, tetapi kami akan tertarik untuk mendengar hasil eksperimen Anda.

Saya dapat menggabungkan sebagian besar dari mereka bersama-sama hanya dengan menggunakan ILRepack pada output /dist/bin/, dan termasuk System.Core.dll. Waktu mulai ditingkatkan setelah menggabungkan sebagian besar perpustakaan, tetapi memperkenalkan banyak bug yang membuat saya tidak tahu bagaimana cara mengatasinya; dan tentu saja Anda kehilangan kemampuan untuk mengandalkan caching untuk potongan kode yang diperbarui tanpa harus mengunduh seluruh gumpalan lagi.

Jadi apakah ada perkembangan tentang ini atau setidaknya ETA? Sisi server bekerja cukup baik tetapi kinerja WASM sisi klien melalui penerjemah masih tidak dapat diterima segera setelah DOM menjadi cukup rumit.

Saya rasa tidak, AOT pada mono repo sepertinya masih WIP; Saya dengar kami akan memilikinya pada Q1 tahun 2020, tetapi saya tidak tahu apakah itu pasti; yang menyedihkan karena saya memiliki pengaturan PWA yang sangat bagus dengan sisi klien tetapi memiliki beberapa masalah kinerja yang mungkin akan diatasi oleh AOT tanpa perlu peretasan yang kotor.

Sementara itu ada beberapa hal yang dapat Anda lakukan untuk mengurangi rasa sakit di sana, yaitu menggunakan DOM virtual dan/atau menggunakan RenderTreeBuilder secara langsung sehingga Anda tidak merender semuanya sekaligus dan memiliki kendali atas apa yang terjadi.

Yah, saya juga bertanya-tanya apakah ada yang berubah sehubungan dengan pengumuman beberapa bulan yang lalu tentang .NET 5 . Kutipan menarik di sana:

Proyek Blazor sudah menggunakan Mono AOT. Ini akan menjadi salah satu proyek pertama yang beralih ke .NET 5. Kami menggunakannya sebagai salah satu skenario untuk membuktikan rencana ini.

Apakah mereka tahu sesuatu yang kita tidak?

Sementara itu ada beberapa hal yang dapat Anda lakukan untuk mengurangi rasa sakit di sana, yaitu menggunakan DOM virtual dan/atau menggunakan RenderTreeBuilder secara langsung sehingga Anda tidak merender semuanya sekaligus dan memiliki kendali atas apa yang terjadi.

Memang. Saya membuat kerangka kerja MVVM dari awal yang terinspirasi oleh WPF dan salah satu hal pertama yang saya lakukan adalah mengganti ShouldRender untuk mematikan pemicu render otomatis Blazor dan sebagai gantinya mengandalkan perubahan properti untuk memberi tahu komponen kapan harus merender ulang. Bahkan satu peningkatan kinerja HUUUUGGGE datang dengan memperbarui gaya melalui interop JS, daripada StateHasChanged , bila memungkinkan.

Meskipun demikian, saya mengalami masalah ketika DOM besar perlu dibuat terlebih dahulu - misalnya, daftar kompleks atau kisi data. Sisi server baik-baik saja, tetapi sisi klien terkadang membutuhkan waktu 5-10 detik hanya untuk merender pada awalnya.

Yang kita butuhkan sebenarnya adalah VirtualizingPanel seperti di WPF. Saya telah memikirkan secara ekstensif tentang bagaimana ini dapat diimplementasikan di interop Blazor dan JS, tetapi solusi lengkap masih belum saya pahami. Di WPF ini berfungsi karena kerangka kerja bertanggung jawab untuk mengukur setiap elemen visual dan melaporkan ukurannya. Bahkan dengan interop JS, saya tidak yakin hal yang sama mungkin terjadi, dan saya belum melihat solusi umum yang baik untuk ini dalam kerangka kerja web apa pun.

SyncFusion memiliki beberapa komponen virtualisasi, yaitu tampilan daftar - tidak tahu cara kerjanya tetapi saya menggunakannya. Mungkin ingin memeriksanya.

Ada juga https://github.com/SamProf/BlazorVirtualScrolling yang juga layak untuk dilihat.

Oh ya saya melihat itu. Senang mengetahui itu bekerja dengan baik untuk Anda. Itu memang memiliki batasan yang signifikan untuk membutuhkan ketinggian barang yang seragam dan ketinggiannya diketahui sebelumnya. Tapi itu bisa menjadi solusi sementara.

Dapatkah seseorang menandai masalah ini dengan tag blazer-wasm? Sulit untuk menemukan masalah ini di tengah semua masalah Blazor sisi server (atau hosting agnostik).

Dan bagi mereka yang mencari ikhtisar untuk pekerjaan Mono WASM AOT yang sedang dilakukan, saya menemukan tautan ini:
https://github.com/mono/mono/projects/11

Keinginanmu adalah perintahku

Terima kasih itu sangat membantu!

Apakah mungkin untuk mendapatkan perkiraan yang paling samar tentang kapan kita dapat mulai menggunakan WASM yang dikompilasi AOT dengan Blazor, bahkan secara eksperimental? 6 bulan? Tahun? Apakah ada orang di tim Blazor yang benar-benar berhasil membuatnya bekerja bahkan dalam mode ad-hoc?

Agak berisiko untuk mulai menginvestasikan banyak waktu, atau merencanakan, Blazor sisi klien ketika kita masih benar-benar tidak tahu seperti apa produk akhirnya. Sebagus sisi server, kami benar-benar membutuhkan versi sisi klien yang andal dan berkinerja baik agar ini dapat berjalan.

Saya telah memposting pertanyaan ini di sini https://github.com/mono/mono/issues/10222 tetapi mendapat jawaban bahwa itu adalah tempat yang salah. Posting ulang di sini:

Diumumkan bahwa Blazor WASM akan dirilis pada Mei 2020. Bisakah kita berasumsi bahwa itu akan menjadi aplikasi WASM asli saat ini? Apa jawaban yang benar?

1. Ya.
2. Kami akan mencoba, tetapi kami tidak yakin.
3. Tidak, itu akan tersedia pada November 2020 dengan .NET 5.0.
4. Tidak, dan kami belum memiliki peta jalan.

Untuk semua penggemar Blazor, ada dua hal yang sangat penting:

• Kecepatan runtime - juru bahasa melambat dalam beberapa kasus penggunaan.
• Ukuran unduhan - semoga Anda dapat mencapai ukuran WASM yang serupa dengan .NET DLL saat ini dan kami akan dapat menghapus mono.wasm sepenuhnya (saya yakin file ini hanya berisi juru bahasa IL - apakah saya benar?).

Saya penggemar berat Blazor sejak awal. Saya tahu bahwa sisi server Blazor memiliki beberapa keuntungan bagi sebagian orang, tetapi kita semua menunggu revolusi nyata - Blazor yang cepat dan andal di browser.

Terima kasih teman-teman atas kerja keras kalian!!!

@Andrzej-W Ini mungkin sedikit menyesatkan bagi siapa saja yang membaca sepintas lalu dan menganggap bahwa November 2020 adalah rilis kanonik.

Secara pribadi saya telah mendengar itu seharusnya keluar secara resmi sekitar Q1 tahun 2020.

Secara realistis, tidak ada yang menghalangi kami untuk mengimplementasikannya ke dalam proses pembuatan kami sekarang sejauh yang saya tahu di luar ukuran yang dapat dieksekusi yang membengkak dan fakta bahwa itu belum didukung oleh Microsoft.

Secara realistis, tidak ada yang menghalangi kami untuk mengimplementasikannya ke dalam proses pembuatan kami sekarang sejauh yang saya tahu di luar ukuran yang dapat dieksekusi yang membengkak dan fakta bahwa itu belum didukung oleh Microsoft.

Apakah ada yang mencoba ini? Saya pikir penting bagi kita untuk setidaknya memiliki bukti konsep sehingga kita dapat melihat bagaimana kinerjanya dibandingkan dengan ditafsirkan dan dibandingkan dengan sisi server. Saya tahu ukuran exe adalah sesuatu yang sedang dikerjakan oleh tim mono, dan itu penting, tetapi kecepatan aplikasi adalah raja. (Dan waktu kompilasi benar-benar tidak relevan IMHO karena kami akan melakukan debugging sisi server dan hanya mengkompilasi ke WASM asli untuk rilis. Waktu kompilasi untuk webpack juga bisa sangat mengerikan).

Di .NET Conf kami mengumumkan bahwa rilis pertama Blazor WebAssembly direncanakan pada Mei 2020. Untuk rilis Blazor WebAssembly pertama ini, kami berharap runtime akan tetap didasarkan pada penerjemah IL yang saat ini kami gunakan.

Tim runtime .NET sedang mengerjakan dukungan kompilasi sebelumnya untuk kompilasi langsung ke WASM. Pendekatan ini memiliki manfaat untuk meningkatkan kinerja waktu proses, tetapi dengan mengorbankan ukuran aplikasi.

Untuk rilis awal Blazor WebAssembly pada bulan Mei, kami sedang menjajaki menjalankan penerjemah IL dalam mode campuran, di mana jalur panas telah dikompilasi ke WASM tetapi sisa aplikasinya adalah rakitan .NET. Ini memberikan kompromi yang bagus antara kinerja runtime dan ukuran aplikasi. Namun, belum jelas apakah ini akan mendarat tepat pada bulan Mei.

Dalam jangka panjang, kami ingin menyediakan SDK yang memberikan kontrol kepada pengembang aplikasi bagian mana dari aplikasi mereka yang dikompilasi langsung ke WASM. Belum ada peta jalan kapan SDK semacam itu akan tersedia.

@lewing @richlander

Terima kasih @danroth27 atas penjelasannya. Ukuran unduhan dapat ditutupi sebagian oleh pra-perenderan sisi server - pastikan https://github.com/danroth27/ClientSideBlazorWithPrerendering ini akan berfungsi di semua rilis Blazor (pra) mendatang.

@danroth27 terima kasih atas pembaruannya! Satu pertanyaan klarifikasi - apakah "tim runtime .NET" merujuk ke tim Mono, CoreRT, .NET 5, atau yang lainnya?

@legistek Mereka semua adalah satu tim sekarang : smile:. Teknologi ini didasarkan pada runtime Mono.

Oh, benar aku lupa. ;D Yang saya maksud adalah apakah

@legistek Yup, semua kerja .NET WASM saat ini terjadi di mono repo.

Saya telah membangun aplikasi yang cukup kompleks yang menjalankan sisi server Blazor sekarang, dan itu bekerja dengan sangat baik. (WASM melalui penerjemah IL, bagaimanapun, sangat lambat sehingga tidak dapat digunakan).

Saya sangat ingin tahu bagaimana itu akan berjalan dengan WASM yang dikompilasi.

Jika kami mengabaikan ukuran unduhan atau waktu kompilasi hanya untuk saat ini, apakah ada cara AOT mengkompilasi aplikasi Blazor ke WASM dan mencobanya? Di mono repo (https://github.com/mono/mono/issues/10222) orang memposting beberapa contoh AOT dengan platform lain seperti Uno, tetapi saya belum melihat contoh Blazor apalagi instruksi tentang caranya untuk melakukannya.

Saya menyadari proses pembangunan akan sepenuhnya ad hoc pada saat ini, tetapi apakah mungkin bahkan pada prinsipnya hanya agar kita dapat merasakan perbedaan kinerja secara kasar? Saya suka sisi server untuk debugging dan demo tetapi saya tidak tahu apakah itu layak untuk penyebaran produksi dalam skala besar. Jadi saya ragu untuk melakukan lebih banyak pekerjaan pada proyek ini sampai saya tahu bahwa kinerja pada AOT WASM akan baik. Saya harus membayangkan ada banyak orang di kapal yang sama.

Hanya untuk menindaklanjuti, saya akhirnya mencoba bootstrap Uno WASM menggunakan WSL (dijelaskan di sini ) dan itu benar-benar berfungsi dengan baik. Masalah ini di sini masih ditandai sebagai DIBLOKIR dan sementara saya tahu mereka masih berupaya mengurangi ukuran muatan yang sepertinya tidak akan memblokir pekerjaan pada rantai pembuatan AOT untuk Blazor, meskipun itu hanya Linux untuk saat ini. Apakah itu yang terjadi dan jika tidak, apa yang ditunggu tim Blazor dari tim Mono sebelum memulainya?

@legistek apakah Anda membangun aplikasi Anda atau yang lainnya? Seberapa jauh lebih baik kinerjanya? Apakah Anda memiliki beberapa metrik untuk dibagikan? Bertanya karena penasaran.

Saya membangun subset aplikasi saya dan kemudian menjalankan beberapa metrik kinerja karena saya tidak dapat menjalankan semuanya tanpa bootstrap Blazor.

Untuk matematika (pembuatan angka acak dan aritmatika sederhana) saya menemukan AOT sekitar 40x lebih cepat daripada yang ditafsirkan.

Yang benar-benar saya minati adalah hal-hal yang saya tahu tidak akan efisien seperti refleksi dan manipulasi string. Aplikasi saya memiliki kerangka kerja pengikatan data khusus yang mirip dengan WPF, jadi saya mencoba menyiapkan pengikatan data yang kompleks dan mengubah nilainya menjadi string acak 10.000 kali. Berikut adalah hasilnya:

Mono Interpreted IL: 2.49s
AOT Penuh (Chrome): 0,702 detik
AOT Penuh (Firefox): 0,5 detik
Asli: 0,067 detik

Jadi pada dasarnya kami memiliki skenario kasus terburuk AOT sekitar 4x lebih cepat dari interpretasi IL, tetapi skenario kasus terbaik sebanyak 40x.

Saya pikir itu mungkin yang diharapkan.

Sayangnya ini masih tidak memberi tahu kami seberapa baik Blazor AOT akan melakukan vs ditafsirkan, tapi saya sedikit pesimis bahwa itu akan berada di sisi bawah (4-5x) karena Blazor mungkin melakukan banyak manipulasi string untuk membangun DOM, dan juga SPA yang canggih akan melakukan banyak panggilan API JSON (yang tentu saja menggunakan refleksi dan string secara ekstensif). Tapi sebenarnya kami tidak bisa memastikan sampai kami benar-benar dapat mencoba aplikasi Blazor yang sebenarnya dengan AOT.

Saya membayangkan kinerjanya akan sangat meningkat dalam waktu dekat karena vendor browser mulai menganggap WebAssembly lebih serius.

Saya pikir AOT membutuhkan lebih banyak penyelidikan lebih cepat daripada nanti karena Blazor kemungkinan akan hidup atau mati dengan reputasi implementasi sisi kliennya di WASM.

Proyek seperti https://d07riv.github.io/diabloweb/ membuktikan tanpa keraguan bahwa WebAssembly lebih dari mampu menangani dirinya sendiri, tetapi saya belum melihat bukti konsep yang sama mengesankannya berjalan di Mono+WASM.

Masalah ini terbuka selama dua tahun.. Apakah ada kemajuan?

@partyelite Ya, ada kemajuan. Ada implementasi kompilasi AoT ke WASM di https://github.com/mono/mono repo dan runtime telah diperbarui untuk mendukung eksekusi campuran .NET IL dan file WASM yang dikompilasi. Namun, dukungan AoT tidak akan siap untuk rilis Mei mendatang. Kami akan meninjau kembali pengirimannya untuk .NET 5.

Saya mencoba opsi kompilasi AOT yang dirujuk Dan dan itu bekerja dengan baik dengan Uno.

Yang masih membuat saya bingung adalah mengapa setidaknya belum ada PoC yang berfungsi dengan Blazor? Saya menyadari bahwa toolchain semuanya masih Linux dan file output jauh lebih besar dari yang kita inginkan, tetapi apa yang mencegah pembuatan contoh aplikasi Blazor yang bekerja dengan AoT sehingga kita dapat mengukur kinerja dan kelayakan?

Saya tidak yakin apakah ini terkait, tetapi pada repositori Syncfusion ada masalah kinerja yang dilaporkan beberapa waktu lalu (https://github.com/syncfusion/blazor-samples/issues/50), dikatakan disebabkan karena kinerja mono yang lambat.

Dalam analisis saya, masalah kinerja menelusuri hingga memanggil js_to_wasm :

Apakah ini sesuatu yang akan diselesaikan oleh ini dan tim mono? Atau ini sesuatu yang tidak berhubungan?

@Herdo mungkin terkait dengan ini: https://github.com/dotnet/aspnetcore/issues/5617

Periksa log konsol web Anda untuk melihat apakah itu GCing berlebihan. Ini tampaknya dimasukkan ke dalam runtime WASM Mono dan perlu IMO yang dapat dikonfigurasi.

@honkmother ,
Bisakah Anda membagikan lebih banyak Info tentang bagaimana Anda berhasil mengemas Blazor DLL dengan ILRepack? Saya menggunakan ILRepack.MSBuild.Task seperti yang dijelaskan di sini . Pengepakan berhasil tetapi ketika saya menjalankan aplikasi saya selalu mendapatkan kesalahan ini:

WASM: System.IO.FileNotFoundException: Tidak dapat memuat file atau rakitan 'netstandard, Version=2.1.0.0, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51' atau salah satu dependensinya.

Tampaknya pengemasan merusak sesuatu, atau pada daftar mencegah bootstrap aplikasi yang benar.

hmm AOT ada di UNO . Bisakah Anda C&P solusi ini?

.Net 5 tidak akan mendukung Kompilasi AoT untuk Blazor?

Itu juga dicoret dari peta jalan.

Saya ingin mendengar komentar resmi sebelum melompat ke kesimpulan, tetapi jika benar ini adalah berita yang sangat buruk yang tidak hanya mempengaruhi Blazor tetapi akan memaksa saya untuk mengevaluasi kembali .NET itu sendiri sebagai platform frontend.

Tidak ada aktivitas yang dilaporkan dalam beberapa bulan di sisi Mono ini:
https://github.com/mono/mono/issues/10222

Mungkin sudah waktunya untuk memotong kerugian dan fokus pada CoreRT sebagai gantinya.

@ram16g @legistek Kami sedang bekerja untuk meningkatkan kinerja runtime Blazor WebAssembly di .NET 5 (dan seterusnya). AoT masih dalam roadmap jangka panjang kami, tetapi pengirimannya akan memakan waktu lebih lama daripada yang kami miliki di .NET 5. Langkah pertama untuk AoT adalah memindahkan Blazor WebAssembly untuk menggunakan pustaka .NET inti yang sama yang digunakan oleh .NET Core, yang juga akan membantu kinerja. Itulah pekerjaan yang sedang terjadi saat ini. Kemudian kita perlu mencari tahu bagaimana membuat AoT bekerja dengan baik dengan IL linking. Pada titik ini, kami pikir kami membutuhkan waktu hingga kuartal pertama tahun depan (pratinjau awal .NET 6) untuk membuat pratinjau pertama dukungan .NET AoT untuk WebAssembly tersedia untuk umum. Tetapi bahkan tanpa AoT, kami masih berharap untuk memberikan peningkatan kinerja yang signifikan untuk Blazor WebAssembly di .NET 5.

Halo @danroth27 , kinerja keseluruhan saat ini tidak terlalu menjadi perhatian saya, tetapi bagaimana dengan kinerja startup awal? Dibutuhkan 2-3 detik setiap kunjungan halaman hingga halaman aktual dimuat, hingga runtime dimuat, DLL yang dikompilasi, dll. Apakah akan ada peningkatan tanpa AOT? Atau apakah kita perlu mengandalkan prarendering?

Hai @MichaelPeter. Waktu buka halaman awal didominasi dengan mengunduh aplikasi dan memulai runtime. AoT tidak akan membantu itu. AoT dimaksudkan untuk meningkatkan kinerja waktu proses, bukan mengurangi ukuran unduhan aplikasi. Untuk runtime berbasis JIT, AoT dapat meningkatkan kinerja startup karena Anda menghindari kebutuhan untuk JIT saat runtime, tetapi Blazor WebAssembly menggunakan runtime berbasis interpreter IL tanpa dukungan JIT.

Kemungkinan besar, AoT sebenarnya akan membuat aplikasi lebih besar untuk diunduh, karena .NET IL adalah format yang lebih ringkas daripada representasi yang dikompilasi secara asli. Jadi menggunakan AoT kemungkinan akan menghasilkan tradeoff antara mempercepat kinerja runtime dengan mengorbankan peningkatan ukuran unduhan. Pemikiran saat ini adalah bahwa kami akan membuat rantai alat AoT tersedia untuk pengembang sehingga Anda dapat memutuskan seberapa banyak aplikasi Anda ingin AoT dan kemudian aplikasi akan berjalan dalam mode campuran, di mana beberapa aplikasi masih berjalan sebagai .NET IL , sedangkan jalur kritis kinerja telah dikompilasi sebelumnya ke WebAssembly.

Untuk meningkatkan kinerja startup aplikasi, kami melihat peningkatan lebih lanjut pada tautan .NET IL dan juga melakukan pekerjaan pada pustaka kerangka kerja inti untuk membuatnya lebih dapat ditautkan. Kami juga berencana untuk melihat kinerja startup dari runtime itu sendiri setelah diunduh.

@ danroth27 Apakah ada masalah yang bisa saya ikuti tentang kemajuan kinerja startup aplikasi? Inilah kekhawatiran terbesar saya saat ini tentang blazer.

@ danroth27 :+1: Terima kasih banyak atas infonya, saya kebanyakan menggunakan Blazor di lingkungan LAN di mana waktu pengunduhan seharusnya hampir nol dan mengira Browser sedang melakukan caching. DLL bersih pula. Tapi dalam Masalah Startup saya juga akan sangat tertarik.

Harap perhatikan bahwa waktu mulai untuk aplikasi berbasis WebAssembly seperti penerjemah Blazor dapat bergantung pada apakah browser melakukan caching file dengan benar. Jika server web yang menghosting aplikasi Anda tidak dikonfigurasi dengan benar atau file telah berubah atau browser tidak dapat men-cache aplikasi, itu harus mengkompilasi ulang dari awal setiap kali Anda memulai aplikasi. Dalam keadaan ideal, browser dapat menyimpannya di cache sehingga kunjungan berikutnya setelah kunjungan pertama Anda akan dimulai lebih cepat.

Anda dapat melihat https://v8.dev/blog/wasm-code-caching untuk informasi tentang ini. Firefox memiliki mekanisme serupa, dan saya yakin Safari juga melakukannya, tetapi saya tidak yakin.

@ danroth27 Saya sangat menghargai penjelasan dan posisi Anda saat mencoba menyiapkan .NET 5 bersama dengan yang lainnya. Beberapa komentar/pertanyaan:

Langkah pertama ke AoT adalah memindahkan Blazor WebAssembly untuk menggunakan pustaka .NET inti yang sama dengan yang digunakan oleh .NET Core, yang juga akan membantu kinerja

Saya berasumsi Anda merujuk untuk beralih ke CoreFX dari Mono mscorlib? Saya pikir itu langkah yang sangat baik jika demikian mengingat banyak tolok ukur kinerja yang diterbitkan menunjukkan CoreFX mengungguli Mono (dan NetFX dalam hal ini) secara signifikan.

Kemudian kita perlu mencari tahu bagaimana membuat AoT bekerja dengan baik dengan IL linking.

Ya menghubungkan telah menjadi rintangan utama untuk sementara sekarang seperti yang telah dibahas di sini . Namun, Uno telah berhasil membuat rantai alat dan mencapai keseimbangan antara ditafsirkan dan dikompilasi yang bisa mendapatkan ukuran aplikasi dalam ~ 10MB atau kisaran remaja rendah. Saya akan berpikir kami setidaknya memiliki PoC untuk ini di sisi Blazor, hanya untuk mulai mengukur metrik kinerja. Tidak tahu apa tingkat kinerja akan meningkat yang paling memprihatinkan saat ini.

Kami juga berencana untuk melihat kinerja startup dari runtime itu sendiri setelah diunduh.

Bagian bangunan DOM ini juga perlu diperhatikan dengan cermat. Memuat aplikasi Blazor yang kosong membutuhkan waktu 1-2 detik di desktop saya dan beberapa detik lagi di perangkat seluler. Setelah tinggal di dunia Angular, saya terbiasa melihat "Memuat ..." setiap kali dan menemukan waktu startup dasar baik-baik saja. Masalah yang lebih besar adalah kecepatan yang sangat lambat dalam membangun DOM yang kompleks. Bahkan DOM dengan 1000-2000 elemen menambahkan sebanyak 5-10 detik untuk pemuatan awal, dan interaktivitas yang melibatkan item kompleks juga menambah jeda yang signifikan. Saya tidak melihat ini dibicarakan banyak dan saya khawatir bahwa (1) AOT tidak akan menyelesaikan ini karena itu endemik interop WASM/JS dan cara string dipertukarkan di antara keduanya; dan (2) mekanisme rendering/diffing di Blazor begitu matang sekarang sehingga sudah terlambat untuk mengubahnya menjadi sesuatu yang akan menjadi kinerja tinggi.

Pemikiran saat ini adalah bahwa kami akan membuat rantai alat AoT tersedia untuk pengembang sehingga Anda dapat memutuskan seberapa banyak aplikasi Anda ingin AoT dan kemudian aplikasi akan berjalan dalam mode campuran,

Persis seperti yang sudah dilakukan Uno,...

Jadi, inilah reaksi dan analisis saya untuk semua ini, dan saya ingin Anda dan semua orang memahami bahwa saya datang ke sini sebagai seseorang yang mungkin sama besarnya dengan penggemar .NET dan Microsoft seperti yang pernah ada. Blazor diperkenalkan ke dunia sebagai kerangka kerja untuk menggunakan _webassembly_ untuk membawa .NET kembali ke browser. Saya sangat gembira ketika saya mengetahuinya. Tapi sekarang sudah lebih dari dua tahun sejak pertama kali diperkenalkan untuk pratinjau dan bagian webassembly masih belum siap untuk aplikasi konsumen karena masalah kinerja yang parah. Sementara itu banyak diinvestasikan di sisi server (yang tempatnya masih belum sepenuhnya saya yakini) dan sekarang mungkin seluler melalui Xamarin, tetapi WASM dapat terus ditendang di jalan lagi dan lagi.

.NET telah kehilangan begitu banyak landasan sebagai platform web frontend sejak SPA mengambil alih dan Silverlight mati berkat plugin pelarangan Chrome. Blazor bisa mengubah semua itu. Tapi saya tidak tahu sekarang apakah Blazor WASM benar-benar ditujukan oleh Microsoft sebagai game changer strategis itu bisa saja atau hanya rasa ingin tahu untuk fanboy seperti saya. Tapi fanboy atau tidak, sebagai pemilik bisnis jika saya memilih kerangka kerja frontend hari ini untuk proyek baru atau membangun kembali yang lama, bagaimana saya membenarkan kepada pendukung saya bahwa Blazor adalah jalan yang harus ditempuh, daripada React atau Angular? Ketika saya membuat daftar pro dan kontra, apa yang tersisa sebagai pro selain saya menyukai C#? Kontra, di sisi lain, terus meningkat.

Jadi saya sangat kecewa dan sedikit demoralisasi. Bukan hanya harus menunggu lebih lama, tetapi masih banyak keraguan tentang apakah teknologi ini akan bertahan, dan saya salah satunya telah menunggu untuk melihat AoT sehingga saya dapat membuat keputusan itu.

Saya tidak mengharapkan kalian untuk mengubah peta jalan Anda atau benar-benar berada dalam posisi untuk meringankan salah satu dari kekhawatiran ini hari ini, tetapi saya pikir itu layak ditayangkan. Saya sangat ingin ini berhasil dan tidak akan menyukai apa pun selain .NET untuk merebut kembali tempatnya sebagai raja aplikasi web interaktif. Tetapi jika saya harus menaruh uang untuk itu hari ini, itu tidak terlihat seperti taruhan yang bagus. Tolong buktikan saya salah!

Saya harus mengatakan bahwa saya berada dalam situasi yang sama dengan @legistek. Saya menggunakan Blazor dari versi 0.1 dan saya penggemar berat teknologi ini. Tentu bagi sebagian dari kita senang memiliki opsi untuk menjalankan Blazor di server. Ini juga merupakan opsi yang menarik untuk memiliki Blazor di ponsel, tetapi saya benar-benar percaya bahwa implementasi WebAssembly harus memiliki prioritas tertinggi. Ini adalah pengubah permainan, itu adalah masa depan.

@ danroth27 untuk blazor, kecepatan deserialisasi JSON sangat lambat untuk daftar objek yang lebih besar, apakah ada panduan tentang cara melakukan ini dengan cepat daripada menggunakan cara juru bahasa yang saat ini lambat.

Saya menemukan ini sebagai hit kinerja terburuk di blazer jika rest apis digunakan dan ukuran data lebih besar sedangkan javascript tidak terpengaruh oleh ukuran di mana saja dengan cara yang sama.

Jika memerlukan proses deserialisasi manual yang akan baik-baik saja untuk daftar yang lebih besar itu, hanya ingin tahu apakah ada panduan tentang ini. Idealnya kita bisa AOT deserialiser?

Untuk menurunkan waktu startup, saya sarankan pemuatan malas. Artinya hanya memuat dll yang diperlukan untuk tampilan atau halaman tertentu. Itu memang akan mempercepat startup

@ram16g @legistek Kami sedang bekerja untuk meningkatkan kinerja runtime Blazor WebAssembly di .NET 5 (dan seterusnya). AoT masih dalam roadmap jangka panjang kami, tetapi pengirimannya akan memakan waktu lebih lama daripada yang kami miliki di .NET 5. Langkah pertama untuk AoT adalah memindahkan Blazor WebAssembly untuk menggunakan pustaka .NET inti yang sama yang digunakan oleh .NET Core, yang juga akan membantu kinerja. Itulah pekerjaan yang sedang terjadi saat ini. Kemudian kita perlu mencari tahu bagaimana membuat AoT bekerja dengan baik dengan IL linking. Pada titik ini, kami pikir kami membutuhkan waktu hingga kuartal pertama tahun depan (pratinjau awal .NET 6) untuk membuat pratinjau pertama dukungan .NET AoT untuk WebAssembly tersedia untuk umum. Tetapi bahkan tanpa AoT, kami masih berharap untuk memberikan peningkatan kinerja yang signifikan untuk Blazor WebAssembly di .NET 5.

Halo semuanya dan @danroth27 , seberapa besar ini akan meningkatkan kecepatan startup (dengan asumsi semua barang di-cache)? Apa yang bisa saya lakukan untuk membantu pengiriman sebelum november? Saya tidak suka menggunakan sudut lagi. ahahahaha saya bersedia menawarkan coding gratis hanya untuk mempercepat ini. Saya tidak terlalu peduli dengan ukuran unduhan awal karena itu hanya akan di-cache. Pengguna sering menjadi pengunjung. angular dapat memulai secara instan ketika file di-cache.

@hoksource Kami tidak memiliki angka pasti tentang bagaimana karakteristik kinerja akan berubah, namun jika Anda mencoba pratinjau dalam 1-2 bulan, Anda seharusnya dapat mengetahuinya.

@hoksource Kami tidak memiliki angka pasti tentang bagaimana karakteristik kinerja akan berubah, namun jika Anda mencoba pratinjau dalam 1-2 bulan, Anda seharusnya dapat mengetahuinya.

@SteveSandersonMS oke jadi
untuk berkontribusi tujuan saya akan dapat melakukan hal berikut:

Opsi 1: Pendekatan langsung (mengatasi masalah secara langsung):
[ ] belajar mengkompilasi proyek mono
[ ] belajar mengkompilasi proyek blazor asp.net
[ ] belajar mengkompilasi blazer asp.net dengan webassembly
[ ] belajar mengkompilasi program klien blazor ke webassembly sepenuhnya (apakah mono->webassembly sudah selesai? dapatkah menggabungkan semua binari referensi menjadi 1 file wasm?)
[ ] periksa apakah mono dapat mengkompilasi seluruh proyek webassembly ke aot web assembly.
[ ] cari tahu cara mendukung semua bahasa c#/.net yang hilang ke webassembly
[ ] temukan struktur penautan yang optimal untuk mengonversi semua dll menjadi 1 file wasm atau beberapa file wasm
[ ] cari tahu cara terbaik untuk melakukannya di atas ukuran dan kinerja file yang menimbang
[ ] pelajari/rancang penautan dan penggabungan binari ke 1 rakitan web atau izinkan pemuatan lambat dengan rakitan parsial
[ ] memiliki serangkaian solusi yang berbeda, pilih beberapa solusi terbaik, berikan kepada kalian. melalui beberapa cabang repositori publik/pribadi dari proyek saat ini

Opsi 2: (mengatasi masalah secara tidak langsung)
[ ] Saya akan melakukan tugas-tugas kecil sederhana seperti modul kecil/mudah/desain/dokumentasi, percaya bahwa insinyur/desainer yang lebih besar dapat memfokuskan/mengarahkan sumber daya mereka pada pendekatan langsung yang dinyatakan pada opsi 1 sebelum rilis nov .net 5.

• pertanyaan tambahan. apakah semua perpustakaan referensi seharusnya open source? saya telah mengkode beberapa perpustakaan, tetapi saya tidak yakin apakah saya ingin mengekspos semuanya secara publik.

Tapi saya pikir opsi 1 akan menjadi pilihan terbaik karena saya tidak akan mengulangi beberapa hal lain yang dilakukan salah satu dari kalian. Mohon konfirmasi jika saya melewatkan sesuatu.

@hoksource Terima kasih atas kesediaan Anda untuk terlibat. Saat ini satu-satunya opsi praktis adalah opsi 1, karena tim Inti ASP.NET sibuk dengan pekerjaan lain. Saya tahu itu adalah banyak hal yang harus Anda pahami, tetapi mudah-mudahan itu membantu menjelaskan mengapa itu bukan sesuatu yang bisa kita selipkan ke dalam tonggak .NET 5 :) Sepertinya Anda memiliki wawasan yang bagus ke dalam berbagai hal yang dibutuhkan di sini.

pertanyaan tambahan. apakah semua perpustakaan referensi seharusnya open source? saya telah mengkode beberapa perpustakaan, tetapi saya tidak yakin apakah saya ingin mengekspos semuanya secara publik.

Terserah Anda apa yang Anda buat open source dan apa yang tidak. ASP.NET Core sendiri adalah open source, tetapi Anda dapat membangun hal-hal sumber tertutup di atasnya jika Anda mau. Kami hanya dapat memasukkan hal-hal open source di repo kami di sini.

Untuk runtime berbasis JIT, AoT dapat meningkatkan kinerja startup karena Anda menghindari kebutuhan untuk JIT saat runtime, tetapi Blazor WebAssembly menggunakan runtime berbasis interpreter IL tanpa dukungan JIT.

Karena penasaran: apakah JITting pada klien menjadi alternatif praktis untuk menafsirkan/menjalankan AoT penuh?

Hai teman-teman! Baru saja melakukan beberapa pembicaraan dengan beberapa tim dan hal-hal lainnya. Tampaknya ini cukup penting untuk perpustakaan seperti SkiaSharp. Bagian utama dari SkiaSharp adalah pustaka asli dan outputnya pada dasarnya adalah file .a yang perlu ditautkan secara statis. Kami _bisa_ berpotensi membangun pustaka asli yang dinamis, tetapi apakah Blazor bahkan mendukungnya?

FYI, saat ini dimungkinkan untuk menautkan statis perpustakaan asli ke runtime. Itu bukan sesuatu yang saya sarankan karena tidak sepele, tetapi Anda bisa melakukannya dan kemudian p/panggil ke perpustakaan yang terhubung secara statis setelah semua bagian ada di sana. Saya tidak tahu apakah kami memiliki kasus uji yang melakukannya sehingga mungkin memerlukan beberapa infrastruktur tambahan yang belum dikirimkan di Blazor. Anda harus mengkompilasi dotnet.wasm/dotnet.js Anda sendiri untuk berintegrasi dengan build Blazor Anda yang bukan untuk orang yang lemah hati.

Perpustakaan asli dinamis adalah masalah lain, pemahaman saya adalah bahwa alat untuk itu di wasm secara umum tidak bagus sekarang, bahkan sebelum Anda sampai pada pertanyaan apakah Blazor mendukungnya.

Saya menemukan tahun lalu bahwa penautan dinamis bukanlah solusi yang layak sama sekali pada saat ini. Emscripten menyiratkan bahwa modul wasm "utama" mencakup semua kemungkinan kombinasi pustaka sistem yang ingin digunakan oleh pustaka dinamis mana pun. Ini membuat modul wasm umum yang sangat besar untuk memulai.

Saya mencoba menggunakan pendekatan itu dengan Uno.SkiaSharp untuk sementara waktu, tetapi itu kasar dan mengesampingkannya (pada saat itu @vargaz mungkin menahan diri untuk mengatakan "sudah bilang" 😂).

Bootstrapper Uno sekarang dapat menggunakan tautan statis (arah di sini ) dan P/Invoke melalui WSL di Windows, dan karena menggunakan jalur eksekusi yang sama dengan yang digunakan interop System.Native internal, sekarang cukup stabil. Anda bahkan dapat melakukan interop dengan mudah dengan modul rust seperti itu.

Saya melakukan beberapa pembacaan, hanya runtime .net yang diubah menjadi wasm. Semua dll diunduh dan diuraikan saat startup. sepertinya wasm runtime yang digunakan adalah mono. Tujuan mereka sekarang adalah menggunakan .net core runtime sebagai gantinya.

Kompiler aot penuh saat ini sedang dilakukan oleh mono, tetapi saya tidak yakin apakah aot penuh dengan .net core harus menjadi jalur/caranya. (Tidak tahu apa yang saya katakan di sini. membutuhkan ahli)

Internet mengatakan .net core berjalan dua kali lebih cepat daripada mono untuk tugas komputasi yang intensif. Startup ini terkait dengan io, pertama-tama unduh binari dan dependensi .dll. (Beberapa file) menguraikannya ke memori. Kemudian mulai aplikasi klien blazor wasm di atasnya. Pengunduhan membutuhkan waktu (tetapi dapat di-cache) dan penguraian memakan waktu cukup lama. Kompiler aot juga tidak tahu mana yang merupakan dependensi dari blazer dan mana yang khusus untuk aplikasi. Akan berantakan jika Anda selalu mengatur dll mana yang akan disertakan dalam aot wasm. Jadi aot penuh terlihat bagus. (Tapi akan lebih cepat dengan implementasi .net core runtime daripada mono? Tidak yakin lagi tentang yang ini) saya juga tidak yakin apakah desain/implementasi kompilasi aot wasm penuh dilakukan dengan runtime mono atau .net. Juga tidak yakin tentang kemajuannya

@danroth27 Apakah ada kemajuan?

Apakah akan tersedia di .NET 5?
Akan menyenangkan untuk memiliki pra-rilis untuk memeriksa fungsi ini juga;)

@redradist AOT tidak akan bisa di komentar danroth27

@hoksource

@redradist AOT tidak akan bisa di komentar danroth27

Sedih :(

Saya punya pertanyaan. Dengan Blazor AOT apakah Anda sedang mengerjakan:

1. kompilasi C# langsung ke format bytecode WebAssembly
2. atau apakah Anda sedang mengerjakan transformasi IL yang dikompilasi dalam .NET DLL ke dalam format bytecode WebAssembly

Pendekatan 2) akan mempertahankan semua alat .NET (termasuk kami) yang mengandalkan IL standar dan metadata yang dikompilasi dan juga PDB agar berfungsi. Juga 2) akan memiliki keuntungan tambahan untuk memiliki System DLL juga disusun untuk WebAssembly, mungkin dengan kode tidak dijalankan pada saat runtime dipangkas (lihat Mono.Linker proyek dengan @JbEvain).
Terima kasih

Btw ada banyak sumber daya di luar sana tentang Blazor tetapi saya tidak menemukan yang dengan perincian yang tepat untuk mendidik diri saya sendiri tentang Blazor Internals, jadi saya menulisnya.

2 bukan 1

Juga, saya berharap proses AoT akan menghasilkan peta sumber yang sesuai (dari wasm ke C#) untuk mempermudah proses debug.

Saya berharap untuk melihat dukungan ini di Q1 2021 untuk rilis pratinjau .Net 6. Ini adalah dasar untuk mendukung repo seperti SkiaSharp yang berjalan secara native di browser web.

Terima kasih telah menghubungi kami.
Kami memindahkan masalah ini ke pencapaian Next sprint planning untuk evaluasi/pertimbangan di masa mendatang. Kami akan mengevaluasi permintaan tersebut ketika kami merencanakan pekerjaan untuk pencapaian berikutnya. Untuk mempelajari lebih lanjut tentang apa yang diharapkan selanjutnya dan bagaimana masalah ini akan ditangani, Anda dapat membaca lebih lanjut tentang proses triase kami di sini .