SetPaketCommand takes half a second

[AlexSugak]

Description

An empty dotnet core 3.1 web app project takes ~1 sec to build 2nd time (no changes). Half of this 1 sec is taken by SetPaketCommand, even when --no-restore flag is set. Should this target be executed at all in this case?

Repro steps

1. With dotnet core SDk 3.1, cd test-proj && dotnet new web.
2. Configure paket as a local dotnet tool, add dependencies and references files.
3. paket install, restore etc.
4. dotnet build .
5. dotnet build . --no-restore /clp:PerformanceSummary

The output has this:

Target Performance Summary:
        ...
        0 ms  Compile                                    1 calls
        0 ms  AfterResolveReferences                     1 calls
        0 ms  CoreBuild                                  1 calls
        0 ms  BeforeResGen                               1 calls
        ...
        0 ms  Build                                      1 calls
        ...
        3 ms  CoreCompile                                1 calls
        ...
       19 ms  PaketRestore                               1 calls
       36 ms  ResolveProjectReferences                   1 calls
       37 ms  GenerateBuildDependencyFile                1 calls
       38 ms  ProcessFrameworkReferences                 1 calls
       52 ms  FindReferenceAssembliesForReferences       1 calls
       53 ms  GenerateBuildRuntimeConfigurationFiles     1 calls
       55 ms  ResolveAssemblyReferences                  1 calls
       67 ms  ResolvePackageAssets                       1 calls
      461 ms  SetPaketCommand                            1 calls
...
Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:01.18

Expected behavior

SetPaketCommand should not take half the build time, preferably it should not be executed at all if --no-restore flag is used

Actual behavior

SetPaketCommand takes ~0.5 sec, which is ~50% of build time.

Known workarounds

N/A

[forki]

Every idea of how to improve it would be appreciated Alexandr Sugak <notifications@github.com> schrieb am Sa., 25. Apr. 2020, 22:05:

…

Description An empty dotnet core 3.1 web app project takes ~1 sec to build 2nd time (no changes). Half of this 1 sec is taken by SetPaketCommand, even when --no-restore flag is set. Should this target be executed at all in this case? Repro steps 1. With dotnet core SDk 3.1, cd test-proj && dotnet new web. 2. Configure paket as a local dotnet tool, add dependencies and references files. 3. paket install, restore etc. 4. dotnet build 5. dotnet build . --no-restore /clp:PerformanceSummary The output has this: Target Performance Summary: ... 0 ms Compile 1 calls 0 ms AfterResolveReferences 1 calls 0 ms CoreBuild 1 calls 0 ms BeforeResGen 1 calls ... 0 ms Build 1 calls ... 3 ms CoreCompile 1 calls ... 19 ms PaketRestore 1 calls 36 ms ResolveProjectReferences 1 calls 37 ms GenerateBuildDependencyFile 1 calls 38 ms ProcessFrameworkReferences 1 calls 52 ms FindReferenceAssembliesForReferences 1 calls 53 ms GenerateBuildRuntimeConfigurationFiles 1 calls 55 ms ResolveAssemblyReferences 1 calls 67 ms ResolvePackageAssets 1 calls 461 ms SetPaketCommand 1 calls ... Build succeeded. 0 Warning(s) 0 Error(s) Time Elapsed 00:00:01.18 Expected behavior SetPaketCommand should not take half the build time, preferably it should not be executed at all if --no-restore flag is used Actual behavior SetPaketCommand takes ~0.5 sec, which is ~50% of build time. Known workarounds N/A — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#3836>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANBEYP4WIICWENV5URTROM7CHANCNFSM4MQ4OCCA> .

[AlexSugak]

I ended up adding RunPaket variable (true by default) to Paket.Restore.targets and modifying Condition of corresponding targets to skip running it if RunPaket is false.

So now I can do dotnet build . --no-restore --no-dependencies /p:RunPaket=false and have build time < 1 sec.

Will Paket override the targets file at some point though?

My use case is that I want to do fswatch on .cs files and run build+test every time something changes. To make it work, the feedback time (time between a file change and a test result) must be small. This is why I am trying to squish as much time out of the build+test pipeline as possible. I don't need to do any package restores here.

[forki]

Yes Paket is adjusting the targets file with every update of itself. So please send a PR to the one here in the embedded folder. That would ensure that we don't break you Alexandr Sugak <notifications@github.com> schrieb am So., 26. Apr. 2020, 13:53:

…

I ended up adding RunPaket variable (true by default) to Paket.Restore.targets and modifying Condition of corresponding targets to skip running it if RunPaket is false. So now I can do dotnet build . --no-restore --no-dependencies /p:RunPaket=false and have build time < 1 sec. Will Paket override the targets file at some point though? My use case is that I want to do fswatch on .cs files and run build+test every time something changes. To make it work, the feedback time (time between a file change and a test result) must be small. This is why I am trying to squish as much time out of the build+test pipeline as possible. I don't need to do any package restores here. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#3836 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAAOANH2YNQTJZES2BWTVE3ROQOCDANCNFSM4MQ4OCCA> .

[inosik]

With your repro steps SetPaketCommand only takes 1-3 ms on my machine. Can you run the build with the -bl parameter and check if this block is executed or not:

Paket/src/Paket.Core/embedded/Paket.Restore.targets

Lines 76 to 78 in 3759237

	<Exec Condition=" '$(PaketExePath)' == '' AND !$(PaketDisableCliTest) AND !$(_ConfigContainsPaket)" Command="dotnet paket --version" IgnoreExitCode="true" StandardOutputImportance="low" StandardErrorImportance="low" >
	<Output TaskParameter="ExitCode" PropertyName="LocalPaketToolExitCode" />
	</Exec>

You can look at the binary log with the MSBuild Binary and Structured Log Viewer.