Home: nuget restore performance issue with kudu
per email from kudu team, nuget restore no-op takes around 22secs with kudu which eventually hit their performance. Ideally a no-op should not have taken this much time even on a slower vm.
Need to investigate and improve restore performance.
jainaashish
All 3 comments
we have two fixes going into 3.5.0-rtm to improve general restore perf.
we've also identified some opportunities for the future.
let's push this remaining investigation (improving no-op) into the future.
rrelyea
on 19 Jul 2016
Can you please share the changes you've made for 3.5.0-rtm?
ericstj
on 17 Aug 2016
So I did some prototyping around this to improve our own builds. At first I just copied the code that is used by the VS extension and gated our restore on that. I saw some considerable improvements, but it was still expensive, even after parallelizing it. We went from 5 minutes down to about 30s, but that 30s was still too much for finding out that nothing needed to be done.
I found that the most expensive cost was doing a full-parse of all the lock files, so I rewrote the parser to only read the necessary parts from the libraries section for checking the packages directory and just used a timestamp comparison to make sure the lock file was up to date. This helped reduce the total cost to roughly 1 second for the entire repo.
See https://github.com/dotnet/buildtools/commit/3e69337852e5b1607c98591c7cc45188e4e8801f.
ericstj
on 17 Aug 2016
Related issues
timotei
路
100Comments
pascalberger
路
68Comments
vsfeedback
路
64Comments
kevinchalet
路
128Comments
joelverhagen
路
242Comments
Most helpful comment
So I did some prototyping around this to improve our own builds. At first I just copied the code that is used by the VS extension and gated our restore on that. I saw some considerable improvements, but it was still expensive, even after parallelizing it. We went from 5 minutes down to about 30s, but that 30s was still too much for finding out that nothing needed to be done.
I found that the most expensive cost was doing a full-parse of all the lock files, so I rewrote the parser to only read the necessary parts from the libraries section for checking the packages directory and just used a timestamp comparison to make sure the lock file was up to date. This helped reduce the total cost to roughly 1 second for the entire repo.
See https://github.com/dotnet/buildtools/commit/3e69337852e5b1607c98591c7cc45188e4e8801f.