Thanks for your report! I think you are saying that if you remove Applicative5 to Applicative14, then the compilation takes a reasonable time. How long does it take? Could you remove enough of the 'Application' types, so the compilation finishes, but takes a long time (on the order of a minute or more)? If you upload that, then we can profile and see if there's anything reasonably easy that we could fix to improve the performance of this very nested case.
(FYI, the slowdown/memory usage is happening in the noding process, not the type checker.)
I've investigated this a reasonable bit. I don't see any easy ways to speed up this example significantly, given our current implementation. We are calling fillinMethods about 180,000 times for different re-instantiated types (e.g. List[T2], where type param T2 is different from the original type param of generic type List). As we currently do things, each local type param in a method is a distinct type, so instantiation of another generic type with that type param creates a new instantiated type that we must create. Potentially, we could do some/most of these instantiations lazily, but that seems like that would be too big of a change for 1.18.
Thank you for the main example and the smaller example that compiles in a minute. I'll keep thinking about this, and we'll certainly keep this example in mind for Go 1.19, if we can't make it faster for Go 1.18.