Nuget Save Cache and Restore 2x slower than just downloading

[clicketyclackety]

I’ve set up my dotnet project with centralised versioning in the Directory.Packages.props file, which I checksum and cache. I can see the nuget packages are ~ 230mb. The usual nuget restore step is 44 seconds. This cache restore shown below is 134 seconds. I thought caching would be worth it, but it seems a bit pointless, any idea why?

Repo : GitHub - crashcloud/Crash: Crash allows you to create shared models which can be interacted with by people within your office, or across the globe.
Workflow : https://app.circleci.com/pipelines/github/crashcloud/Crash/24/workflows/6c86f001-256e-43b2-8579-a6bd3b91b08e/jobs/22

My caching steps

      - restore_cache: 
           name: Restore Nuget Package Cache 
           key: nuget-{{ checksum "Directory.Packages.props" }}-{{ .Environment.CACHE_VERSION }} 
           paths: 
             - "~/.nuget" 
  
       - run: 
           name: Check for Cache 
           command: | 
             try 
             { 
               $no_nuget = (ls ~\.nuget\packages).Length -eq 0 
               $exit_code = if ($no_nuget) { 1 } else { 0 } 
               exit $exit_code 
             } 
             catch 
             { 
               exit 1 
             } 
  
        - run: 
            name: Restore NuGet Packages 
           command: nuget restore Crash.sln 
           command: dotnet restore Crash.sln --use-lock-file 
           when: on_fail 
  
       - save_cache: 
           name: Cache Nuget Packages 
           key: nuget-{{ checksum "Directory.Packages.props" }}-{{ .Environment.CACHE_VERSION }} 
           paths: 
             - "~/.nuget" 
           when: always

– cs

[rit1010]

The issue may be just the level of compression that the cache uses to keep the cache file small, while also operating additional corruption checks during downloads.

The cache can work very well if the remote repository has slow access or access restrictions, but if the remote repository can operate at high speed it is possible that it will operate faster.

One other possibility is that the cache feature is not as multi-threaded as ‘nuget restore’, so nuget is able to make better use of the 4 vCPUs available during the download/unpack steps.

[clicketyclackety]

Thankyou @rit1010 ,
I guess I’ll go for nuget restore then as it’ll use less credits