Observing exponential lint time on chained methods

[yurikhan]

Hi. I’m seeing behavior that is likely a bug in one of the upstream linter implementations, but I’m not going to have the time to narrow it down to a specific linter, so posting it here in hope that someone gets triggered and hunts it down 😅

There is this SQL construction library called Squirrel. Among other things, you can build a table update statement with multiple parameters:

query := builder.Update("some_table").
	Set("column1", value1).
	Set("column2", value2).
	Set("column3", value3).
	Where(squirrel.Eq{"id": 42})

Today I needed to add two .Set()s to a chain that already had 31. And as I ran the linting stage, it just got stuck and timed out in an hour.

I took some measurements and found that as long as I have 20 chained .Set()s or fewer, linting takes about 15 seconds (± noise). But each added .Set() after that multiplies the linting time by progressively increasing factors — 1.1, 1.2, 1.5, 1.7, 1.9.

TL;DR: at least one of the linters included in golangci-lint is exponential in the number of chained methods.

(The workaround is to split the chain into two or more smaller ones.)

[Antonboom]

Hi!
Could you provide your .golangci.yml or link to reproducible example?