v1.47.1 much slower

[fredbi]

Welcome

• Yes, I'm using a binary release within 2 latest major releases. Only such installations are supported.
• Yes, I've searched similar issues on GitHub and didn't find any.
• Yes, I've included all information below (version, config, etc).
• Yes, I've tried with the standalone linter if available. (https://golangci-lint.run/usage/linters/)

Description of the problem

Today, our CI pipelines moved to v1.47.1 and we immediately felt the pain:
linting was suddenly taking about 3x longer, exhausting the resources of the CI VM (2 vCPU, 4GB RAM), even with a very small amount of changes and the "--new-from-rev master" flag. This behavior was consistent and observed on a dozen PRs today, even those with no change in the go code base.
run is slower when compared to v1.46.2, which was our previous version.

Running v1.47.1 from docker image: golangci/golangci-lint:latest-alpine
Extra installations required for alpine:
apk add git openssh-client bash ncurses gcc musl-dev

CLI for linting:
golangci-lint run --timeout 10m --new-from-rev master --build-tags integration

Version of golangci-lint

golangci-lint version running on the CI container.

$ golangci-lint --version
golangci-lint has version v1.47.1 built from ebd6dcbf on 2022-07-19T11:57:02Z

Configuration file

$ cat .golangci.yml
linters-settings:
  govet:
    check-shadowing: true
  gocyclo:
    min-complexity: 25
  maligned:
    suggest-new: true
  dupl:
    threshold: 150
  goconst:
    min-len: 3
    min-occurrences: 2
  forbidigo:
    forbid:
      - ^print.*$
      - 'fmt\.Print.*'
  funlen:
    lines: 100
    statements: 50
  gocognit:
    min-complexity: 80 # This is super high value. We should gradually lower it to 30-40.
run:
  skip-dirs:
    - integrationtest

linters:
  enable:
    - gofmt
    - goimports
    - bodyclose
    - dupl
    - forbidigo
    - gocognit
    - gocritic
    - goimports
    - gosec
    - nakedret
    - nolintlint
    - revive
    - stylecheck
    - unconvert
    - unparam
  disable:
    - maligned
    - lll
    - gochecknoinits
    - gochecknoglobals

Go environment

go version running on the CI container.

$ go version && go env
go version go1.18.4 linux/amd64
GO111MODULE="on"
GOARCH="amd64"
GOBIN=""
GOCACHE="/root/.cache/go-build"
GOENV="/root/.config/go/env"
GOEXE=""
GOEXPERIMENT=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOINSECURE=""
GOMODCACHE="/go/pkg/mod"
GONOPROXY="github.com/oneconcern/*"
GONOSUMDB="github.com/oneconcern/*"
GOOS="linux"
GOPATH="/go"
GOPRIVATE="github.com/oneconcern/*"
GOPROXY="https://proxy.golang.org,direct"
GOROOT="/usr/local/go"
GOSUMDB="sum.golang.org"
GOTMPDIR=""
GOTOOLDIR="/usr/local/go/pkg/tool/linux_amd64"
GOVCS=""
GOVERSION="go1.18.4"
GCCGO="gccgo"
GOAMD64="v1"
AR="ar"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD="/root/project/go.mod"
GOWORK=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build3438759853=/tmp/go-build -gno-record-gcc-switches"

Verbose output of running

$ golangci-lint cache clean
$ golangci-lint run -v
# paste output here

Code example or link to a public repository

N/A (private repo)

[ldez]

Hello,

is slower than which version?

have you tried to disable some linters to detect if it's a specific linter?

[fredbi]

Editing description: slower when compared to v1.46.2

[ChrisSargent]

Seems to be related to the revive linter for use - once we enable that the linter just keeps going and going..... (tried a binary search disable to pinpoint it)

[killianmuldoon]

Also seeing this issue on Cluster API. I've managed to pin it down a bit and will continue tomorrow. I'm seeing golangci-lint hang forever on the Cluster API test directory with only revive enabled. When I run revive i.e. installed with go install on the directory it seems to run instantly so I'm not certain what the root cause is.

[Prajyot-Parab]

I have noticed the same with (v1.47.0 & v1.47.1), once I disable revive linter everything works smooth, with revive enabled it seems to take a lot of toll on the resources and eventually times out. (checked in cluster-api-provider-{ibmcloud,azure,gcp})

[fredbi]

I ran in verbose mode on the CI container and got funny timings (reporting some stages at more than 1 hour when the whole process took 3-4 min to complete). Apparently, the reports indicates that the most time consuming stage is the_only_name, but I've no idea what linter this refers to.

the_only_name: 1h3m59.009993044s

golangci-lint run --timeout 10m --new-from-rev master --build-tags integration -v
INFO [config_reader] Config search paths: [./ /root/project /root /] 
INFO [config_reader] Used config file .golangci.yml 
INFO [lintersdb] Active 23 linters: [bodyclose deadcode dupl errcheck forbidigo gocognit gocritic gofmt goimports gosec gosimple govet ineffassign nakedret nolintlint revive staticcheck structcheck stylecheck typecheck unconvert unused varcheck] 
INFO [loader] Using build tags: [integration]     
INFO [loader] Go packages loading at mode 575 (exports_file|files|name|types_sizes|deps|imports|compiled_files) took 1.501450313s 
INFO [runner/filename_unadjuster] Pre-built 0 adjustments in 109.68306ms 
WARN [linters context] bodyclose is disabled because of go1.18. You can track the evolution of the go1.18 support by following the https://github.com/golangci/golangci-lint/issues/2649. 
INFO [linters context/goanalysis] analyzers took 1h37m31.082369227s with top 10 stages: the_only_name: 1h3m59.009993044s, buildir: 3m16.320011246s, forbidigo: 1m59.338176485s, gosec: 1m59.221088858s, goimports: 1m56.739021701s, dupl: 1m47.316641529s, gocritic: 1m46.3872796s, gofmt: 1m4.491736962s, S1038: 54.1605421s, directives: 51.906138566s 
WARN [linters context] structcheck is disabled because of go1.18. You can track the evolution of the go1.18 support by following the https://github.com/golangci/golangci-lint/issues/2649. 
INFO [runner/skip dirs] Skipped 13 issues from dir app/resolvers/integrationtests by pattern integrationtest 
INFO [runner/skip dirs] Skipped 2 issues from dir app/apihandlers/integrationtests by pattern integrationtest 
INFO [runner/skip dirs] Skipped 5 issues from dir app/grpcgeodude/integrationtests by pattern integrationtest 
INFO [runner/skip dirs] Skipped 1 issues from dir app/notifier/integrationtests by pattern integrationtest 
INFO [runner] Issues before processing: 2856, after processing: 0 
INFO [runner] Processors filtering stat (out/in): path_prettifier: 2856/2856, nolint: 0/171, filename_unadjuster: 2856/2856, identifier_marker: 646/646, exclude: 646/646, cgo: 2856/2856, skip_files: 2856/2856, skip_dirs: 2835/2856, autogenerated_exclude: 646/2835, exclude-rules: 171/646 

[Prajyot-Parab]

I bumped my Golang binary to v1.18.4 and also the upstream codebase (cluster-api-provider-ibmcloud project) Golang to v1.18.4, issue got fixed for me, linters working smoothly.

@killianmuldoon ^^^

Update - Need to confirm same for other project codebases (may not be a stable solution)

[josephlr]

We also ran into a similar issue when updating to 1.47.1

[fredbi]

@Prajyot-Parab

I bumped my Golang binary to v1.18.4

My initial report was already running go v1.18.4. This is not likely to be a fix.