Closed phisco closed 1 year ago
Hey, thank you for opening your first Issue ! 🙂 If you would like to contribute we have a guide for contributors.
Hello,
$ golangci-lint version
golangci-lint has version 1.53.2 built with go1.20.4 from 59a7aaf7 on 2023-06-03T15:04:31Z
$ git clone git@github.com:upbound/provider-aws.git
Cloning into 'provider-aws'...
$ cd provider-aws
$ golangci-lint run
WARN [runner] The linter 'interfacer' is deprecated (since v1.38.0) due to: The repository of the linter has been archived by the owner.
7m35s $
$ golangci-lint run
WARN [runner] The linter 'interfacer' is deprecated (since v1.38.0) due to: The repository of the linter has been archived by the owner.
2s $
Note: the 2nd call to golangci-lint run
uses only the cache, so the problem is not related to the use of the cache.
If I disable musttag
:
$ golangci-lint run
WARN [runner] The linter 'interfacer' is deprecated (since v1.38.0) due to: The repository of the linter has been archived by the owner.
1m37s $
Also, your graph shows that it's related to musttag only.
You checked the following box:
- [X] Yes, I've tried with the standalone linter if available (e.g., gocritic, go vet, etc.). (https://golangci-lint.run/usage/linters/)
Can you provide the output and the duration of standalone binary of musttag?
The problem is related to the go list
calls inside musttag
https://github.com/tmzane/musttag/blob/main/utils.go
So it's a problem with musttag, it's a side effect of a bug fix.
thank you @ldez for the super quick reply! yes, this was the same conclusion I came to, should I open an issue on the musttag
linter instead? looks like the repo was moved from github.com/junk1tm/musttag to github.com/tmzane/musttag, right?
here the output running it via govet, not much:
$ time go vet -vettool=$(which musttag) ./...
go vet -vettool=$(which musttag) ./... 2672.40s user 1363.83s system 749% cpu 8:58.46 total
and here the output running it directly with debug logs enabled:
time musttag -debug fpstv ./... 130 ↵
15:54:10.850971 load [./...]
15:54:13.490103 building graph of analysis passes
... I'm still waiting, I'll update this once it finishes ...
I was looking at my clone and thought I did pull the latest changes but I did not 😅 : I also noticed golangci-lint is using v0.5.0 of musttag, while the latest seems to be 0.7.0, but it doesn't look like that should change the code running the go list
🤔
I also noticed golangci-lint is using v0.5.0 of musttag
golangci-lint used v0.7.0. https://github.com/golangci/golangci-lint/blob/d147d8bf4f8530fb0384614a4ebcc1defe0796bc/go.mod#L118
yes, sorry, I edited the message above, I was looking at an old version of the repo and forgot to pull
just for sharing: The reason behind the issue, it's that your project has a lot of small packages, so a lot of Run
and a lot of go list
. It's not related LOC but the number of packages.
Makes sense, thanks! I'll let the maintainers know that reducing the number of packages could be another option.
Btw, I'll take the chance to thank you for this awesome project, I've been using it for a few years now and I couldn't work without it 🙏
I created a fix, the output with your repo and my changes:
$ ./golangci-lint run
1m53s $
@ldez feel free to close this issue or to keep it around until the musttag dependency is bumped 👏 thank you so much again!
Edit to add the missing context: A new version was released with the fix https://github.com/tmzane/musttag/issues/55
I will close it when PR #3924 will be merged.
Welcome
Description of the problem
On https://github.com/upbound/provider-aws, and other similar projects, we saw some major performance degradation upgrading from an older version to v1.50.x, we tried doing some investigation back then and couldn't find any obvious reason, we ended up bumping the specs of our runners, which was enough to solve the issue. We now tried looking into into it further, given that we also want users to run it locally before opening a PR, so we did some more analysis and discovered most of the time was lost on the
musttag
linter this time as you can see from the syscall graph below: Just disabling it we are now back at a much healthier resource consumption and graph, we went from crashing due to the default 10m timeout withmusttag
enabled to having it successfully run in around 2 minutes after having disabled it. Taking care to have cleaned up the cache before every run withgolangci-lint cache clean
. Here the graph with musttag disabled:Tests run on MacBook Pro 14" M1 Pro 32GB, but also on a linux box with similar results.
We couldn't find any other similar issue, we are indeed running it successfully on https://github.com/crossplane/crossplane/ , so maybe there is something pathological with our projects that triggers such a behaviour, but could be worth investigating nonetheless.
Version of golangci-lint
Configuration file
Go environment
Verbose output of running
Code example or link to a public repository