It can be fast:

Perhaps consider not using dotnet install script or is the option to contribute a fix to dotnet install script?

Hi @jetersen, we will try to resolve this problem.

Hi Team - any news on this?

Hello @PureKrome,

So far no updates

The problem is not reproduced anymore.

Based on multiple runs, the action does not take more than 15 seconds.
https://github.com/akv-demo/dotnet.restore.slow.github.action/actions/runs/6729109167

Most probably, the root cause of the problem was an infrastructure issue that has currently been resolved.

In case the problem reoccurs, the solution is to avoid bulk copying to the OS drive, similar to the workaround applied for the same problem in the actions/setup-go: actions/setup-go#393

@jetersen did it help?

@dsame I do not agree with the assessment that it is not reproducible 😓
Even with cache available Windows Server 2022 is still 20 seconds slower.
Creating the cache is still 1 minute longer than time of Ubuntu when running Windows Server 2022.

So definitely an improvement but I feel like windows can perform better.

https://github.com/jetersen/dotnet.restore.slow.github.action/actions/runs/6736238225
https://github.com/jetersen/dotnet.restore.slow.github.action/actions/runs/6736262624

I don't think it is fair to say look it is fixed for the actions/setup-dotnet when we are talking about a simple if check to see if .NET 6 is already available on the actions runner image 😓

Testing with .NET 8 preview shows ubuntu with 7 seconds vs +30 seconds sometime a little less. For actions/setup-dotnet.

https://github.com/jetersen/dotnet.restore.slow.github.action/actions/runs/6736383956/job/18311632176

While this issue remains open: #141 this will definitely not improve 😢

Thank you @jetersen for pointing out .NET 8 issue, it's confirmed

https://github.com/akv-demo/dotnet.restore.slow.github.action/actions/runs/6742358650/job/18328332807

@dalyIsaac interesting approach, does that really save that much 🤔

I'm fairly happy with the gains I've seen, but admittedly I didn't conduct a very rigorous study.

Hello @jetersen

The quick fix is to set environment variable DOTNET_INSTALL_DIR to the value pointing to some path on the "D:" drive.

akv-demo/dotnet.restore.slow.github.action@45e801a#diff-b803fcb7f17ed9235f1e5cb1fcd2f5d3b2838429d4368ae4c57ce4436577f03fR15

This workaround is proven to solve the problem https://github.com/akv-demo/dotnet.restore.slow.github.action/actions/runs/6768243557/job/18392290993 and can be used until the action fix is available

@dsame perhaps some of these fixes should be raised with @actions/runner-images? I assume we are hitting similar IO restrictions on the Windows images as this affects all windows based hosted runners 🫠

Hello @jetersen, generally it is a good idea but i doubt any of actions team can solve the problem with the infrastructure and most probably the infrastructure problem is not expected to be solved in the acceptable timeframe.

but i doubt any of actions team can solve the problem with the infrastructure

why is this? because these are 2 independent teams within GH and even though the actions team could make some changes based on this thread (which would benefit all users, by default) ... the intra-team still need to also do some changes but you're suggesting that this is a low priority so .. they go 'meh' ?

Created actions/runner-images#8755 in hoping that we can find a generic solution. I was hoping they could simply change the disk setup on the windows packer scripts 🤔

hi

Hi @jetersen 👋,
As mentioned by the runner-images team in this issue comment, unfortunately, there is no simple fix to align the C: drive's performance with the D: drive due to inherent limitations, and these are not expected to be resolved in the near future.

However, a feasible workaround is to set the DOTNET_INSTALL_DIR environment variable to a path on the D: drive to enhance build performance. You can configure it like this:

env:
  DOTNET_INSTALL_DIR: D:\dotnet

Please feel free to reach out if you have any concerns or need additional assistance.
Thanks!

Thank you! I tested this. Note that this is only applicable to standard (4-core for public, 2-core for private repos) runners, not to larger ones, as those don't have a D drive.

Results are here: It seems to make things slower. What do you think?

Hi @Piedone,
Thank you for sharing your observations. Could you share the reproduction link or the specific runs used for the performance comparison of the NuGetTest and root workflows? This information would help us better understand the performance results.

Sure, thank you! In my test, we're building the solution file in the root of our OSOCE project, as well as the solution in the NuGetTest folder. Runs:

• D drive runs for the NuGetTest solution
• D drive runs for the root solution
• Non-D drive runs for both the root and NuGetTest solutions

You can disregard the failing builds; some parts of the workflow are flaky.

The following steps of the executed jobs are directly using the .NET SDK:

• Set up .NET: runs setup-dotnet plus some configuration.
• Build and Static Code Analysis: runs dotnet build and related things.
• Tests: runs dotnet test for unit and UI tests.

@priyagupta108 I tested with my repro:

There is a definite improvement. But still setup/dotnet install is still incredibly slow when comparing it to Linux or Mac.
So I still think there are improvements to be had in the usage of dotnet-install script.
The difference is Ubuntu 6 seconds vs Windows 16 seconds for the actions/setup-dotnet@v4 run step.
Which shows that install script is doing something it shouldn't.

The .sh relies on curl or wget. Why couldn't Windows rely on curl? GitHub actions runner have curl installed and in my experience avoids any overheads that Powershell or Invoke-WebRequest has when it comes to downloading files.

Hi @Piedone,
Thank you for sharing the information. Changing the DOTNET_INSTALL_DIR to the D drive has indeed improved the performance for the setup-dotnet step. However, the performance of dotnet build and dotnet test commands may not be significantly impacted by the installation directory of the .NET SDK alone.
To potentially enhance performance further, consider setting the NUGET_PACKAGES environment variable to a directory on the D drive, which may allow faster access to cached packages.

Hi @jetersen,
Thank you for your insights! We will investigate this further and see if we can implement these changes to enhance performance. We will consider this as a potential feature request for future improvements. In the meantime, please feel free to provide any additional details or suggestions you may have.

Thanks for the tip! This was very useful, since setting NUGET_PACKAGES reduced the workflow runtimes by 14-25%, see Lombiq/GitHub-Actions#402 (comment). I also did a test in a private repo with a .NET Framework build, and got a ~6% reduction there.