With the merging of the dev.typeparams branch, a number of the types in go/types picked up additional fields that are only used during the type checking pass. Many users of go/types (particularly gopls) are sensitive to the memory footprint of a type checked package. Filing this issue as a reminder for go1.17: we should verify that we're not pinning memory unnecessarily.
I did a quick check using both pprof and a memory debugging tool that @heschi is experimenting with for gopls, and they indicated that typechecked packages in go1.17 consume perhaps 5-10% more memory than in go1.16. We're not yet convinced that these are accurate numbers, but such a relative change is probably meaningful. If accurate, a 5-10% increase is not so bad, though we could probably eliminate it.
Update: measured a couple ways, I was consistently seeing around a 6% increase in memory footprint when working on x/tools. CL 318849 should unpin the Checker, which in my testing almost exactly reclaimed the 6% regression.
I also tried externalizing object.color_ and object.order_ into maps, but this didn't seem to make much difference in memory footprint and slowed down the type checking pass by 2-4%. There may be something worth pursuing there, but not for 1.17.
When importing generic named types, it is possible for Checker.newNamed
to be called during type instantiation when the Checker is nil.
In this case we should be able to safely skip this delayed expansion.
Trust: Robert Findley <firstname.lastname@example.org>
Run-TryBot: Robert Findley <email@example.com>
TryBot-Result: Go Bot <firstname.lastname@example.org>
Reviewed-by: Robert Griesemer <email@example.com>