Can you show us your code? Without that, it will be hard for us to look into it.

It's possible to show code privately under NDA. Works for you?

No, I'm not signing an NDA.

Let me check. Maybe I can collect/provide some info which would be helpful?

It would be interesting to see the output of go tool nm on the binaries before and after.

ok. Can we send them to email in your github profile?

Sure.

Likely closely related to #51957 .

@mdempsky This issue would at least be partially fixed by moving away from self-contained object files. Thin object files might help with the cpu, and almost certainly would help with the build cache size.
(They have a large package that then gets imported up the dependency tree several steps.)

Like @randall77 mentions, we're aware the compiler's intermediate files are larger than ideal, and unfortunately generics further aggravates that weakness. We have ideas about how to address that and intend to do those, but they're not trivial and will take time to implement and deploy.

You also mention the size changes were due to switching to generics, which means your application code must have changed. That makes interpreting your benchmarks harder. For example, you say your CI now takes almost 3x as long, and suggest that's because generics are slower. But from your description, there's also the possibility that changing the application has simply created 3x more work for the compiler to do.

I expect it's some of both. Certainly the compiler could be faster, but other projects are using generics successfully. For now, I think your best options are:

1. Experiment with refactoring how you're using generics to reduce the overheads to acceptable levels.
2. Find examples of generics code where overhead grows superlinearly with source complexity. We try to use O(N) algorithms throughout the compiler, but sometimes we make mistakes and an O(N^2) algorithm sneaks in.

@xaurx could you clarify exactly what "Cold CI build time" means? Is that the time it takes merely to run go build on your project on a fresh worker?

@cespare yes, it's a fresh worker using the same code cache, i.e. not downloading it again. To reproduce locally I used go clean -cache between the runs:

w/o generics:

$ go clean -cache
$ time make
  129.74s user 23.57s system 400% cpu 38.242 total
$ du -sh go-build
760M    /Users/user/Library/Caches/go-build
$ go tool nm tool.before| wc -l
73861

w/ generics:

$ go clean -cache
$ time make
  817.00s user 89.57s system 558% cpu 2:42.33 total
$ du -sh go-build
4.4G    /Users/user/Library/Caches/go-build
$ go tool nm tool.after | wc -l
80238

as you can see, after adding generics compile time becomes 4.2x slower and takes 5.7x more disk space in go-build cache.

@mdempsky see exact commands I used to reproduce in above message. i.e. it's not about some other changes in the code. any fresh build after go clean -cache takes 4.2x more time.

Please note, any package which imports the one used generics now takes so much significantly more time to build. Since we import it a lot of times - it adds up and overall build takes long.
Additionally, I tried to compile with GC_FLAGS="-S" and generics generate 15.5x more output and much more symbols. So my guess is that it was optimized out by linker and nm doesn't reveal a huge difference, but compiler spent so much time...