dotnet/aspnetcore

Build performance improvements for Blazor

mkArtakMSFT opened this issue · 8 comments

mkArtakMSFT commented

For .NET 5 we plan to handle only this piece of work, which will later be part of the bigger Hot reload story for Blazor and potentially for all ASP.NET Core.

msftbot commented

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

pranavkm commented

A couple of things jump out that would help in the inner loop:

  • Any changes to a .razor file results in the declaration assembly being compiled, and tag helpers being discovered. If the change to a razor file is markup only, we could avoid doing this extra work.

  • Any change to a razor file results in all declaration and generated files being regenerated.

    • Declaration files generally do not need to be regenerated if the input is unchanged. I say generally because you could do something funky such as change the LangVersion or RazorLangVersion that could also change the declaration file, but these are rare occasions.
    • Regenerating the generated file could also be made incremental based on the input file and the tag helper discovery i.e. if the structure of other components do not change, we do not need to regenerate a component.

The time spent in code generation scales linearly with the number of razor files. Changing this would benefit projects with a large number of .razor files.

  • In Blazor WebAssembly, every build results in recalculating hashes on a bunch of files including runtime assets which remain unchanged unless you update the SDK. Calculating these hashes accounts for ~8% of our the inner loop for a standalone project. These values can be cached between builds.

  • The next set of items would be improving the inner loop with project to project references. This is being tracked by #23073

  • 👍2
pranavkm commented

We're done with the work for 5.0. At this point, there's a risk of introducing bugs when making changes in the SDK. Parking this in the backlog to get back to addressing the additional investigations in 6.0.

msftbot commented

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.

mrlife commented

We're done with the work for 5.0. At this point, there's a risk of introducing bugs when making changes in the SDK. Parking this in the backlog to get back to addressing the additional investigations in 6.0.

Does this mean the work is done but won't be released until November 2021?

pranavkm commented

@mrlife we addressed (1) of the 3 items listed above and that's available as part of the rc1 SDK (#24445). Doing (2) is a bit risky this late in the release. I might still do (3), but the savings (~100ms) and there are other things I'd like to address for 5.0.

  • 👍1
msftbot commented

Thanks for contacting us.
We're moving this issue to the Next sprint planning milestone for future evaluation / consideration. We will evaluate the request when we are planning the work for the next milestone. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

msftbot commented

We've moved this issue to the Backlog milestone. This means that it is not going to be worked on for the coming release. We will reassess the backlog following the current release and consider this item at that time. To learn more about our issue management process and to have better expectation regarding different types of issues you can read our Triage Process.