Razor Class Library Build Time Serious Regression with .NET 9 SDK

TimPurdum commented 2 days ago

Is there an existing issue for this?

[x] I have searched the existing issues

Describe the bug

Build time for a Razor Class Library with significant static assets (JavaScript files) is more than 4x slower with the .NET 9 SDK than with the .NET 8 SDK.

| SDK Version | 1st Build (after clean/restore) | 2nd Build |
|-------------|---------------------------------|-----------|
| 8.0.404     | 36.95 s                         | 23.90 s   |
| 9.0.100     | 143.5 s                         | 123.8 s   |

Expected Behavior

I would expect no such regression without changing code or at least target level. This appears to be driven mostly by the new ResolveProjectStaticWebAssets logic, which takes more than 50% of the length of the build, with a good bit of what's left being used by the other "StaticAsset" build steps.

Steps To Reproduce

Make sure you have 8.0.404 and 9.0.0 SDKs installed
Clone https://github.com/dymaptic/GeoBlazor

In the src folder, set the global.json to

{
  "sdk": {
    "version": "8.0.0",
    "rollForward": "latestMinor"
  }
}

Just to prove that these aren't related, you can delete or comment out all the custom Targets in dymaptic.GeoBlazor.Core.csproj (otherwise you do need npm and pwsh installed as well)
Navigate to src/dymaptic.GeoBlazor.Core in a terminal, and run the following commands
```
dotnet clean
dotnet restore
dotnet build -f net8.0
dotnet build -f net8.0
```
Edit the global.json file, replace 8.0.0 with 9.0.0
Run the commands from step 4 again

Exceptions (if any)

No response

.NET Version

No response

Anything else?

I expect this is going to be a big issue for any other libraries that wrap significant JavaScript modules. At the very least, I need a workaround to ameliorate this regression so I can move this library to .NET 9 and beyond.

javiercn commented 1 day ago

@TimPurdum thanks for contacting us.

We've identified some performance issues when dealing with large sets of assets. We are working on performance improvements for future SDK releases. I just tested with your project and the build seems to speed up significantly.

  dymaptic.GeoBlazor.Core net8.0 succeeded (6.3s) → bin\Debug\net8.0\dymaptic.GeoBlazor.Core.dll
  dymaptic.GeoBlazor.Core net7.0 succeeded (13.4s) → bin\Debug\net7.0\dymaptic.GeoBlazor.Core.dll
  dymaptic.GeoBlazor.Core net6.0 succeeded (13.4s) → bin\Debug\net6.0\dymaptic.GeoBlazor.Core.dll

Build succeeded in 17.0s

There's more work that is happening on the performance side of things to further optimize large asset collections. In the meantime, there are a couple of things you can do:

Exclude from the build any asset that you don't need to ship.
Disable static web assets during development/inner loop.
- This will limit your ability to use MapStaticAssets in an app, but if you are producing a library, it should be fine. You can still rely on app.UseStaticFiles during development.

TimPurdum commented 1 day ago

@javiercn appreciate the prompt response! I was thinking I couldn't use Disable Static Assets as that sounds pretty drastic! 😅 But I will give it a go.

Cutting down our dependencies is a long term goal, but difficult to do for a library where you don't know what features the end user will use.

dotnet / aspnetcore