blazor big project: build perf downgrade

[AdmiralSnyder]

Is there an existing issue for this?

• I have searched the existing issues

Describe the bug

our blazor project in our 180 project solution takes ages to compile which is very painful for debugging.
after an inital build after deleting bin and obj folders, which took 145 seconds,
a consecutive build takes 122 seconds.
Without any changes between those builds.

This is especially painful since when i did changes in source, it takes 4+ minutes every time i hit F5 in Visual studio.

We already tried inspecting the binlogs to find the causes, but didn't get to anything specific

Here, i'm linking .binlog files that got created immediatly one after the other
firstbuild
secondbuild

Any help is greatly appreciated

this might be a hint to start the investigation:

(in the second build)

Expected Behavior

when there's no source changes, the second call for dotnet build should take almost no time

Steps To Reproduce

i am very happy to show anybody around the project on discord, please ping me. since this is our closed source commercial product, i cannot share it, though.
and since the extend of the problem only hits with a big project like this (that's our theory, at least), i don't know how to create a minimal solution

Exceptions (if any)

no exceptions, sadly. it is just super slow

.NET Version

10.0.101

Anything else?

We first started noticing slowdown when fingerprinting assets was introduced in blazor, last year.
also, this might not be relevant, but it became way worse when i turned a number of of intermediate projects from being netstandard2.0 to multitargeting net10.0 and net48, a couple months ago

[AdmiralSnyder]

why do we lose 40 seconds on calling lots of build targets that are skipped? which skip is the expensive one?

[javiercn]

@AdmiralSnyder thanks for contacting us.

Looking at the binlog I see about 10s total spent in static assets. You can use <DisableBuildCompression>true</DisableBuildCompression> in Directory.Buid.props on the root folder of your solution. (You can try dotnet build /p:DisableBuildCompression=true for a quick test) you'll get around 4-5s improvement at most from SWA (probably less because it's slower when running with binnary logging enabled), but I see most of the time spent elsewhere in the build.

[dotnet-policy-service]

Hi @@AdmiralSnyder. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.