-
Notifications
You must be signed in to change notification settings - Fork 5.2k
Description
Description
I have a Blazor Web project which I build/deploy through Azure DevOps (using Aspire/azd tools).
I've found that to get reasonable UI performance with certain third party UI chart controls where there is a lot of user interaction and JS interop, I need to use AOT compilation with this in my Web.Client project file:
<PropertyGroup>
<RunAOTCompilation>true</RunAOTCompilation>
<WasmStripILAfterAOT>false</WasmStripILAfterAOT>
</PropertyGroup>
The build/deploy time for my Blazor web app with AOT compilation enabled with a standard 'windows-latest' agent on Azure DevOps has crept up to nearly 2 hours which seems pretty crazy. It looks locally like its spending most of it's time in the wasm aot compile step.
I've used Azure Managed agent pools to get an on demand 16 core machine as an agent and that brings the build time down to about half an hour, which still seems like quite a long time.
Overall, this issue does make deploying the end to end microsoft web tech stack (.NET, Blazor, Azure DevOps, Azure) both slow but also very power hungry and therefore wasteful from an energy/CO2 perspective. As such, I hope it's something you can prioritize. I've no idea how many of your customers are trying to do the same, but it would be good to get the time/energy down.
Is there anything in the pipeline or ticket I can track for improvements to Blazor AOT compile time?
I'm going to experiment with the 'EmccLinkOptimizationFlag' elements I've found in another thread to see how that effects the balance of compile time vs. size and performance, but I'm hoping there's something more fundamental in the works.