x/tools/cmd/stringer: stringer should not use go/types

[robpike]

It takes much longer to run stringer on a program than to compile it. Stringer should be nearly instantaneous, but I suspect the new importer technology is killing performance. Something certainly is.

At tip, wiith a freshly written file, so the build cache has the dependencies but not the output of building list.go itself:

% go version
go version devel +47be3d49c7 Thu May 10 23:19:40 2018 +0000 darwin/amd64
% cat list.go
package main

import (
	"gopkg.in/src-d/go-license-detector.v2/licensedb/filer"
)

func main() {
}

type Type int

const (
	Other Type = iota
	A
	B
	C
	D
)

func getFiler(file string) filer.Filer {
	return nil
}
% time go build

real	0m1.617s
user	0m1.290s
sys	0m0.408s
% time stringer -type Type

real	0m4.197s
user	0m2.409s
sys	0m0.782s
%

Stringer is taking almost 3 times as long to run as it takes to compile and link the binary. That's crazy. If we remove the dependency on filer, which has a pretty big set of dependencies itself, stringer runs quickly again.

[ianlancetaylor]

My understanding is that the plan to make things better again is #14120 (comment) .

[griesemer]

I suspect the stringer is using the default setup of go/types which is using a source importer (rather than an importer based on gc-compiled export data). As a consequence, each time stringer is run, it type-checks not only the file containing the stringer directive, but also all imported packages, recursively, all the way down...

(That is, in fact it's surprisingly fast doing all this work... :-)

It may be sufficient to simply configure types.Config with the gc importer for now (if my hunch above is correct).

[griesemer]

@robpike Since you have a good test case, would you mind doing the following change and see what the difference is:

diff --git a/cmd/stringer/importer19.go b/cmd/stringer/importer19.go
index deddadb1..ed08eab4 100644
--- a/cmd/stringer/importer19.go
+++ b/cmd/stringer/importer19.go
@@ -12,5 +12,5 @@ import (
 )
 
 func defaultImporter() types.Importer {
-       return importer.For("source", nil)
+       return importer.For("gc", nil)
 }

I suspect this should fix it.

Maybe this should be settable with a flag?

(As an aside, we can probably get rid of the support for Go 1.8 now (importer18.go)).

[robpike]

That change gives me an error that it can't find the filer import.

I gave you a full reproducible example. It requires importing a big thing but it's not hard to reproduce.