Larger projects can now effectively be TDD'd in. Or rather you modify or fix a test in a test file and the tests compile and execute very fast. Or even simply the call to `go run`, `go build` and `go test` will be significantly faster.
This is the kind of difference I'm getting
GOCACHE=off time go build
16.36 real 37.02 user 6.43 sys
GOCACHE=on time go build
0.66 real 0.53 user 0.37 sys
Number of files including vendor dependencies (some files may not actually be imported)
Those 2 runs are between 2 runs where something different change right? Thats effectively just outsourcing the 'did I change anything' memory to the cache system?
I'm ok with that I guess and I suppose I see the benefit when running multiple package test runs where their aren't dependencies between them. But I've just not seen the utility in practice, and it seems like it can introduce bugs where the cache is used incorrectly.
You are right, no changes. With a change, most objects are still valid as cached and can result in similar speedup. I'm also wary of caching introducing bugs and intend to continue to CI without it as a safety net. May even require a no cache build before pushing commits.
This is the kind of difference I'm getting
GOCACHE=off time go build
GOCACHE=on time go build Number of files including vendor dependencies (some files may not actually be imported)find . -name '*.go' | wc -l