"dotnet run --no-restore --no-build --no-launch-profile" significantly slower than "dotnet exec <path-to-dll>"

[lafritay]

Describe the bug

After building a fairly large dll, this command (run from the project directory):

dotnet run --no-restore --no-build --no-launch-profile

takes 8 seconds longer than running this command:

dotnet exec

I understand that dotnet run may add some overhead but 8 seconds seems like way too much. This does not happen with a fresh project so it seems that something specific to my project or environment is causing the issue. I've added logging to ensure that the program has the same PWD and the same number of managed assemblies are loaded. I've taken hostlog traces and can confirm that the overhead is coming before my app is invoked.

Further technical details

See the attached hostlog traces and timestamps within. "run.hostlog.txt" is the one from "dotnet run" that has the additional overhead.

run.hostlog.txt
exec.hostlog.txt

[baronfel]

fundamentally there are very different mechanisms at play here:

• dotnet exec never touches the .NET SDK at all - it's all the native muxer directly launching your app.
• dotnet run has to load the .NET CLI's dll, parse CLI arguments, then the run command itself executes and does at least one MSBuild evaluation of your project to gather data used to execute the application.

Having said that, 8 seconds is pretty excessive, but we also don't have good user-facing ways to trace the performance/execution of this stuff. We're trying to move to OTel for our telemetry, which would make it very possible to get good traces of where the time is being spent and give us better ideas of where to spend the time.

[lafritay]

My suspicion is that it has to do with some large folders that live in the project directory. All of those folders are excluded from the project itself though. Any thoughts on if there's a full file scan in there that could be causing this or other things I could try in order to diagnose where the time is being spent?

[baronfel]

Good thinking - the globbing of auto-included files can definitely take a while. We've done some work in .NET 10 to optimize this a bit, what version of the SDK are you using?

[lafritay]

net9.0.304

[marcpopMSFT]

This should be one of the scenarios we look at with #49667