Gelio
commented
2 years ago We would have to add a benchmark first to verify that this update is actually an improvement. According to this StackOverflow comment, creating goroutines can have an extra cost which would offset the benefit of doing the introspection in parallel. This means the benefit here would be present only during the initial go-global-update run when the go cache is cold. go list -m seems to be a lot faster for a few minutes after it checked a package once, presumably because it caches the information about the latest version.
All in all, I don't think that the improvement will be large enough to invest time into creating a benchmark and then implementing parallel introspection.
Maybe if I knew how to disable go list -m cache so it always hits the network and the command execution time would be stable then it would be a good time to implement the benchmark. Without that, the execution time of go-global-update --dry-run with a hot go list -m cache is around 0.5s:
11:15 $ time go-global-update --dry-run
Binary Current version Status
go-global-update v0.2.0 up-to-date
gofumpt v0.3.1 up-to-date
gotop v4.1.2 can upgrade to v4.1.3
misspell v0.3.4 up-to-date
shfmt v3.4.3 up-to-date
real 0m0,556s
user 0m0,159s
sys 0m0,110swhich seems good enough for now.
I will leave the issue open in case someone has an idea how to disable go list -m cache so we can create a reliable benchmark.
At the moment, binaries are introspected sequentially
https://github.com/Gelio/go-global-update/blob/2a645e2a168c312e6ab7ab06e33b3d27db942292/internal/gobinaries/introspect_binaries.go#L13-L23
That could be done in parallel because introspecting one binary should be independent from introspecting another binary. This should make the CLI a bit faster (although there are no currently known performance problems related stemming from that problem).
sync.WaitGroupseems like a good-enough construct to use.