[過去ﾛｸﾞ] 【本命】Blazor スレ1【真打】 (1002ﾚｽ)
上下前次1-新
抽出解除 必死ﾁｪｯｶｰ(本家) (べ) 自ID ﾚｽ栞 あぼーん

---

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索 歴削→次ｽﾚ 栞削→次ｽﾚ 過去ﾛｸﾞﾒﾆｭｰ

---

471(1): デフォルトの名無しさん [sage] 2020/08/19(水)01:13 ID:x2lHzzgW(1/4)
そもそも、DesktopのC#は、AOTでどのくらい速くなるの？
特にサイズはどのくらい変化する？
小さくなるの？
なるとしたら何分の一になる？

---

475(2): デフォルトの名無しさん [sage] 2020/08/19(水)01:49 ID:x2lHzzgW(2/4)
>>474
Blazorとは関係なく、もともとのWindows環境のWinFormsやWPFなどで、
AOTを使った場合が、使わない場合と比べてどのくらい速くなるか、ということ。

---

476(1): デフォルトの名無しさん [sage] 2020/08/19(水)01:50 ID:x2lHzzgW(3/4)
>>473
この板で、小さくなると言ってた人を見かけたけど、どうなの？

---

481: デフォルトの名無しさん [sage] 2020/08/19(水)02:07 ID:x2lHzzgW(4/4)
Hi @MichaelPeter. The initial page load time is dominated by downloading the app and starting
the runtime. AoT won't really help that. AoT is intended to improve runtime performance,
not reduce the app download size.
For JIT based runtimes AoT can improve startup performance because you avoid the need
to JIT at runtime, but Blazor WebAssembly uses an IL interpreter based runtime without
any JIT support.

In all likelihood, AoT will actually make the app larger to download, because .NET IL is a more
compact format than its natively compiled representation.
So using AoT will likely result in a tradeoff between speeding up runtime performance at the
expense of increased download size.
The current thinking is that we will make the AoT toolchain available to developers so that
you can decide how much of your app you want to AoT and then the app will run in a mixed
mode, where some of the app still runs as .NET IL, while the performance critical paths are
precompiled to WebAssembly.

To improve the app starup performance we are looking at further improvements to the
.NET IL linker and also doing work to the core framework libraries to make them more linkable.
We also plan to look at startup performance of the runtime itself once it is downloaded.

---

上下前次1-新書関写板覧索設栞歴

---

ｽﾚ情報 赤ﾚｽ抽出 画像ﾚｽ抽出 歴の未読ｽﾚ AAｻﾑﾈｲﾙ

---

ぬこの手 ぬこTOP 0.049s