In my post this week I'm getting Inside PGO to explore how the Go compiler uses a CPU profile to make your program faster without changing a single line of your code.
The profile gets trimmed down to call edges: which function called which and how often. With that, the compiler does three things:
1. Guarded devirtualization: at an interface call, it picks the type with the most samples and adds a type check with a direct call to it.
2. Inlining: hot calls get an inline budget of 2000 instead of 80.
3. Loop alignment (x86 only): loops in hot functions get padded so they start at the beginning of a cache line.
I walk through all of it with a small shapes program and its real profile edges.
Today I'm writing about the Go's Profile-Guided Optimization (PGO), where you hand the compiler a profile of a real run and it optimizes the code that is actually hot, without touching your source.
One interesting fact is that the compiler doesn't use the whole profile, it just keep a subset of the information, the "call edges" (caller, callee, where the call happens, and how many samples hit it).
From those edges, the compiler does three things: guesses the concrete type behind interface calls, inlines much bigger functions at hot calls, and aligns hot loops to cache lines. We will see each of those in detail.
Today is guess day in my blog. Please welcome @ainsleydev, Go Developer Advocate at @JetBrains, founder of the agency ainsley.dev, and the person behind the GoDaily newsletter. Today he follows `//go:embed` all the way from a comment in your source to bytes in your binary.
He guide us throgh the different components of the go toolchain.
- The go command (runs once) spots your `//go:embed` comments, expands patterns like `assets/*` into real files on disk and store that.
- The compiler validates the directive, reads each file and lays its bytes out as read-only data.
- The linker joins everything with the runtime, and your file ends up in the binary's read-only data section.
He also covers the runtime side plus the tradeoffs, like why you should never embed secrets.