Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

dotnet restore performance problems

See original GitHub issue

I recently converted a solution with around 65 C# projects, all in the new sdk-format, from nuget to paket. I used convert-from-nuget, resolved the detected conflicts and did a paket simplify. I also removed all but one version restriction.

Paket.dependencies contains around 40 nuget packages
frameworks are restricted to netstandard2.0, net47, netcoreapp2.0
Storage is set to none.
Paket version is 5.167.2
Before building, i clean all obj and bin folders.

With nuget, a dotnet restore took around 9 seconds. With paket, the dotnet restore takes around 1:30 min. Is this expected or am i possibly doing something wrong?

Issue Analytics

State:
Created 5 years ago
Comments:27 (20 by maintainers)

Top GitHub Comments

3reactions

semyon2105commented, Jul 1, 2020

We started having these performance problems after transitioning to .NET Core. I did some benchmarking and discovered that Paket performs more than 3 times slower than PackageReference on initial build and in builds that are run after paket install.

test result

The benchmarking was done in a Linux VM (4 CPU threads, 8 GB RAM, SSD). All the tests were run with populated local package cache, nothing was being downloaded over the network. Paket also used storage: none mode.

All test results are available here

The long initial restore problem is especially annoying in Visual Studio or Rider. After switching from one branch to another with more dependencies, both IDEs start the restore process which takes even more time than the CLI restore, about twice as much.

I would say the dotnet CLI build time increase is tolerable but the slowdown in IDE workflows is a deal breaker.

Is there something that can be done to improve the restore times or is there a hard design decision that makes it infeasible?

0reactions

kblohmcommented, May 27, 2018

I just stopped deleting the obj folders 😉. Although after switching branches, VS is sometimes not happy until i do a rebuild. If that does not really help with performance, its probably not worth it. About the task for two runtimes: if anybody is interested, this does kind of describe how to handle that case (you two probably know how that works, but i am not really versed in msbuild;)).