golang/go

cmd/compile: exponential compile-time with nested generic instantiations

Open

#78342 opened on Mar 25, 2026

View on GitHub
 (2 comments) (0 reactions) (0 assignees)Go (133,883 stars) (19,008 forks)batch import
NeedsFixToolSpeedcompiler/runtimehelp wanted

Description

Go version

go 1.26.1 / tip

Output of go env in your module/workspace:

GOARCH=arm64

What did you do?

case 1:

package p

type T[P any] struct { _,_,_,_,_,_,_,_ P }

type U T[T[T[T[T[T[T[T[T[T[int]]]]]]]]]]

case 2:

package p

type T[P any] struct { _,_,_,_,_,_,_,_ P }

type U T[T[T[T[T[T[T[T[T[T[T[int]]]]]]]]]]]

case 3:

package p

type T[P any] struct { _,_,_,_,_,_,_,_ P }

type U T[T[T[T[T[T[T[T[T[T[T[T[int]]]]]]]]]]]]

Run go build on the above and measure the time.

What did you see happen?

Very long compile time.

What did you expect to see?

Fast compilation.

Contributor guide

Tech stack
go
Domain
performance
Issue type
bug
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
5
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
over 1 week
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
fresh
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
clear
Prerequisites
knowledge of Go generics
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
10
Research direction
Investigate the type substitution algorithm in the Go compiler's generic instantiation code, likely in cmd/compile/internal/types2 or similar. Look for exponential growth in nested instantiations. Consider adding memoization or limiting recursion depth. The issue provides test cases with increasing depth (10, 11, 12).