-
Notifications
You must be signed in to change notification settings - Fork 520
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PaketRestoreLockFileHash = PaketRestoreCachedHash slow #2796
Comments
I have no idea why a simple read on a file with 3k lines would take as long as this. Basically all we want is a way to check if something changed. This is the only practical cross-platform way I could come up with. As nice as such unix tricks are you cannot really assume that
Please feel free to send a solution as I couldn't find one, sorry. I give up on this one (I never noticed such slowdowns so I guess you have a slow hard drive? Or it is a osx/linux problem?) |
Unless my ssd is going bye bye that shouldn't be the issue. Yeah maybe this should be pushed upstream. I also looked for some simple tricks like file size but you're right finding a crossplat solution is not simple. |
Fired up my windows box, yeah this seems local to at least osx. :sad_panda: |
Something a bit more x-plat for osx/linux. Just check for the existence of shasum and awk. If they aren't there just fallback to normal
|
Bleh. Just noticed you'll get output like
Why are we using msbuild again? |
Description
Using
dotnet restore -v diag
it spends a lot of time onPaketRestore
:I narrowed
Paket.Restore.targets
down to these lines with a large enough lock file (case about 2500 lines) theReadAllText
functions is extremely slow.Repro steps
Generate a
paket.lock
file of about 2500 lines long.Expected behavior
Actual behavior
Known workarounds
This is not a permanent solution but for comparison if i use the built in
shasum
function on osx/linux:The text was updated successfully, but these errors were encountered: