New CLI version is very slow on Windows

[shubham1172]

Dapr CLI v1.7.0-rc.2 is considerably slower than v1.6.0 on Windows.

Script used: https://gist.github.com/shubham1172/80846320d8a33bd4a39f65edd9177133

############################
       dapr --version
############################
v1.6.0

Avg: 175.652ms
Min: 137.4927ms
Max: 1076.538ms


v1.7.0

Avg: 1009.2455ms
Min: 894.5307ms
Max: 1164.4052ms

############################
       dapr --help
############################
v1.6.0

Avg: 172.6062ms
Min: 152.1281ms
Max: 211.8084ms


v1.7.0

Avg: 1026.8171ms
Min: 952.4243ms
Max: 1228.9317ms

############################
       dapr help
############################
v1.6.0

Avg: 182.6562ms
Min: 154.2751ms
Max: 299.4941ms


v1.7.0

Avg: 1240.0274ms
Min: 962.4161ms
Max: 2512.6125ms

############################
       dapr list
############################
v1.6.0

Avg: 394.1212ms
Min: 280.7828ms
Max: 897.2138ms


v1.7.0

Avg: 1687.809ms
Min: 1476.0607ms
Max: 2296.0588ms

Release Note

RELEASE NOTE: FIX Performance on Windows

[shubham1172]

/assign

[shubham1172]

Some more findings:

1. Dapr CLI v1.7.0-rc.2 is not slow if Dapr runtime is uninstalled
2. Dapr CLI v1.7.0-rc.2 is slow even if it points to an older Dapr runtime version (v1.6.0 instead of v1.7.0-rc.1)
3. On timing the individual cli/pkg functions, they perform almost the same for v1.6.0 and v1.7.0-rc.2.

A major change from v1.6.0 to v1.7.0-rc.2 was Go upgrade from 1.16 to 1.17.

[berndverst]

Confirmed that there is no slowness on Linux or Mac

On both M1 Arm Mac with Arm64 binaries and Linux with AMD64 binaries CLI 1.7.0-rc.2 is not any slower than CLI 1.6.0. I went through GitHub bisect also.. but there are no noteworthy differences.

[berndverst]

Please also consider that the Go version used to compile may be a culprit here. As of 2 days ago Windows binaries are compiled with 1.17.8, before that it was 1.17.7. CLI 1.6.0 was compiled with a different version altogether.

If Go version can be ruled out (by compiling 1.6.0 again with 1.17.8), use Git Bisect to find the offending commit:

git checkout v1.7.0-rc.2
make
# time the following
./dist/..../dapr.exe --version

git bisect start
git bisect good v1.6.0
git bisect bad v1.7.0-rc.2


# now git will suggest a commit
make
# time the following
./dist/..../dapr.exe --version

# now decide if the numbers are good or bad and tell git bisect. For example bad:
git bisect bad

# now git will suggest a new commit etc etc

[shubham1172]

The problem is with the go compiler version. I tried using different compiler versions with different CLI versions and here are the results (100 runs per command)

############################
       dapr --version
############################
v1.5.1 release version, compiled with go 1.16

Avg: 328.5328ms
Min: 275.4623ms
Max: 487.1119ms


v1.6.0 release version, compiled with go 1.16

Avg: 354.2701ms
Min: 276.5343ms
Max: 641.7528ms


v1.6.0 compiled with go 1.17.6

Avg: 1103.3831ms
Min: 864.4201ms
Max: 2993.4135ms


v1.7.0 release version, compiled with go 1.17

Avg: 1149.8473ms
Min: 996.1999ms
Max: 1666.1498ms


v1.7.0 compiled with go 1.17.1

Avg: 1762.9062ms
Min: 1297.8131ms
Max: 2375.0072ms


v1.7.0 compiled with go 1.17.6

Avg: 1837.149ms
Min: 1357.621ms
Max: 2893.892ms


v1.7.0 compiled with go 1.17.8

Avg: 1448.4474ms
Min: 1173.2539ms
Max: 1782.6383ms


v1.7.0 compiled with go 1.18

Avg: 1292.3167ms
Min: 978.8401ms
Max: 2791.5266ms

Now, CLI v1.7.0 cannot be downgraded to use go 1.16 because of a pkg dependency introduced by #894. See kubernetes-sigs/controller-tools#643.

[shubham1172]

Phew, test results from a brand-new Windows VM:

############################
       dapr --version
############################
v1.6.0 release version, compiled with go 1.16

Avg: 155.8055ms
Min: 134.0364ms
Max: 218.5515ms


v1.7.0 release version, compiled with go 1.17

Avg: 125.6285ms
Min: 110.9377ms
Max: 160.8203ms


############################
       dapr help
############################
v1.6.0 release version, compiled with go 1.16

Avg: 150.4167ms
Min: 129.6965ms
Max: 256.1846ms


v1.7.0 release version, compiled with go 1.17

Avg: 123.6194ms
Min: 110.8603ms
Max: 159.5841ms

The problem was likely with my computer, which had tons of software running. Closing this issue!