wire: caching fails to make tests run instantaneously about wire HOT 4 CLOSED

Looking at the source code for the go test command, the computeTestInputsID function apparently computes the hash of every file that got opened during the first test run. That would explain why the time to run the test varies with the number of subtests being run (taking a slice) even for a cache hit. So it's possible that the overhead for computing all these hashes is making the tests slow on cache hits. If so, it might be possible to speed up that case by putting all the test data into a zip file.

from wire.

Update: I tried putting the testdata directory into a zip file and updating the test to work with that, but got no significant speedup on cache hits. It's puzzling.

from wire.

@zombiezen is saying the slowdown could be the result of the tests opening a bunch of Go standard library packages for type checking. go test would have to check the hashes of all those files to see if it's a cache hit, and that could take a while.

from wire.

This is not a wire issue. It's an issue in go test. See golang/go#26726.

from wire.