Go Defer — Optimize¶

Instructions¶

This document covers the cost of defer and how to optimize it (or avoid it) when it matters. Each section presents a problem, a measurement, and an optimization where applicable. Difficulty: Easy, Medium, Hard.

We assume Go 1.22+ on amd64. All benchmarks use go test -bench with -benchtime=2s -count=5. Numbers are typical, not exact — your mileage will vary by CPU.

1. The Cost Model¶

Critical thresholds: - 9 defers in a function disqualify open-coded — drop to stack-allocated. - One defer inside a loop disqualifies the entire function from open-coded. - Calling recover from outside a deferred function in the same function disables open-coded. - -gcflags=-N (no optimization) disables open-coded.

2. Baseline Benchmark¶

A minimal benchmark to establish numbers on your machine.

package deferbench

import (
    "sync"
    "testing"
)

var mu sync.Mutex

//go:noinline
func work() {}

func directCall() {
    mu.Lock()
    work()
    mu.Unlock()
}

func openCodedDefer() {
    mu.Lock()
    defer mu.Unlock()
    work()
}

func deferInLoop() {
    for i := 0; i < 1; i++ {
        mu.Lock()
        defer mu.Unlock()
        work()
    }
}

func BenchmarkDirectCall(b *testing.B) {
    for i := 0; i < b.N; i++ {
        directCall()
    }
}

func BenchmarkOpenCoded(b *testing.B) {
    for i := 0; i < b.N; i++ {
        openCodedDefer()
    }
}

func BenchmarkLoopDefer(b *testing.B) {
    for i := 0; i < b.N; i++ {
        deferInLoop()
    }
}

Typical result on Go 1.22, M1, single-threaded:

BenchmarkDirectCall-8    150000000   8.0 ns/op    0 B/op   0 allocs/op
BenchmarkOpenCoded-8     120000000  12.5 ns/op    0 B/op   0 allocs/op
BenchmarkLoopDefer-8      30000000  60.0 ns/op   16 B/op   1 allocs/op

The ~4ns overhead of open-coded defer is invisible in any real workload. The 60ns loop-defer (with allocation!) shows up in profiles.

3. Exercise 1 (Easy) — Defer In Hot Loop¶

Problem:

func processAll(items []Item) {
    for _, it := range items {
        func() {
            defer it.Cleanup()
            it.Process()
        }()
    }
}

Even though it.Process is the hot work, the per-iteration defer adds cost.

Question: How much overhead per iteration, and what's the fix?

func processAll(items []Item) {
    for _, it := range items {
        it.Process()
        it.Cleanup()
    }
}

func processAll(items []Item) {
    for _, it := range items {
        processOne(it)
    }
}

func processOne(it Item) {
    defer it.Cleanup()
    it.Process()
}

4. Exercise 2 (Easy) — 9 Defers Crossing The Threshold¶

Problem:

func setup() {
    defer cleanup1()
    defer cleanup2()
    defer cleanup3()
    defer cleanup4()
    defer cleanup5()
    defer cleanup6()
    defer cleanup7()
    defer cleanup8()
    defer cleanup9() // crosses the 8-defer threshold
    work()
}

Question: What's the cost difference between 8 and 9 defers?

func setup() {
    defer cleanupAll()
    work()
}

func cleanupAll() {
    cleanup1(); cleanup2(); ...
}

5. Exercise 3 (Medium) — Recover Disqualifies Open-Coded¶

Problem:

func safeFn() (err error) {
    defer func() {
        if r := recover(); r != nil {
            err = fmt.Errorf("recovered: %v", r)
        }
    }()
    risky()
    return nil
}

Question: Does recover disqualify open-coded defer?

6. Exercise 4 (Medium) — Mutex Hot Path¶

Problem: a high-throughput cache with millions of get/set per second:

func (c *Cache) Get(key string) string {
    c.mu.RLock()
    defer c.mu.RUnlock()
    return c.data[key]
}

Profile shows Cache.Get is hot. The defer is ~4 ns of ~30 ns total per call (~13%).

Question: should you remove the defer?

func (c *Cache) Get(key string) string {
    c.mu.RLock()
    v := c.data[key]
    c.mu.RUnlock()
    return v
}

func (c *Cache) Get(key string) string {
    c.mu.RLock()
    v := c.getLocked(key)
    c.mu.RUnlock()
    return v
}

func (c *Cache) getLocked(key string) string {
    return c.data[key]
}

7. Exercise 5 (Medium) — Heap Allocation Profile¶

Problem:

func process(items []Item) {
    for _, it := range items {
        defer it.Close()
    }
    // ...
}

Question: how much memory is allocated?

BenchmarkLoopDefer-8   30000000  60 ns/op  48 B/op  1 allocs/op

func process(items []Item) {
    for _, it := range items {
        processOne(it)
    }
}

func processOne(it Item) {
    defer it.Close()
    // ...
}

8. Exercise 6 (Medium) — Defer Vs Manual Cleanup In Close¶

Problem: a struct's Close method:

func (s *Service) Close() error {
    s.mu.Lock()
    defer s.mu.Unlock()
    if s.closed { return nil }
    s.closed = true
    if err := s.conn.Close(); err != nil {
        return err
    }
    return s.db.Close()
}

Question: is the defer worth it here?

9. Exercise 7 (Hard) — Trace Span With Negligible Overhead¶

Problem: every public method has a trace:

func (s *Service) Foo(ctx context.Context, req *Req) (resp *Resp, err error) {
    defer trace(ctx, "Foo", &err)()
    // ...
}

The deferred trace closure logs duration and error.

Question: what's the cost?

func trace(ctx context.Context, name string, errp *error) func() {
    start := time.Now()
    return func() {
        elapsed := time.Since(start)
        if *errp != nil {
            metrics.Observe(name+".error", elapsed)
        } else {
            metrics.Observe(name+".success", elapsed)
        }
    }
}

func (s *Service) Foo(ctx context.Context, req *Req) (resp *Resp, err error) {
    var span Span
    span.Start(ctx, "Foo")
    defer span.End(&err)
    // ...
}

10. Exercise 8 (Hard) — PGO And Defer¶

Problem: a function with one defer is called from a hot loop:

func main() {
    for i := 0; i < N; i++ {
        helper()
    }
}

func helper() {
    mu.Lock()
    defer mu.Unlock()
    work()
}

Question: does PGO help?

go build -o app
./app -cpuprofile=default.pgo
go build -pgo=default.pgo -o app2

11. Exercise 9 (Hard) — Pre-1.14 Era Code Migration¶

Problem: code written for Go 1.10 explicitly avoided defer for performance:

// Pre-1.14 hot path: avoid defer for ~30 ns/call savings
func get(key string) string {
    mu.RLock()
    v := data[key]
    mu.RUnlock()
    return v
}

After upgrading to Go 1.14+, the cost of defer dropped from ~30 ns to ~4 ns.

Question: should you re-add the defer?

12. Exercise 10 (Hard) — Inlining Inhibition¶

Problem:

func wrap(fn func() error) error {
    start := time.Now()
    defer log.Info("took", time.Since(start)) // ← does this prevent inlining?
    return fn()
}

Question: does the defer prevent wrap from being inlined?

go build -gcflags="-m=2" 2>&1 | grep wrap

func wrap(fn func() error) error {
    return wrapWithLog(fn)
}

//go:noinline (or just keep it complex)
func wrapWithLog(fn func() error) error {
    start := time.Now()
    defer log.Info("took", time.Since(start))
    return fn()
}

13. PProf Snippets¶

Before (defer in loop)¶

File: app
Type: cpu
Showing nodes accounting for 250ms, 50% of 500ms total

      flat  flat%   sum%        cum   cum%
     150ms 30.0%  30.0%      150ms 30.0%  runtime.deferproc
     100ms 20.0%  50.0%      100ms 20.0%  runtime.deferreturn

deferproc and deferreturn together are 50% of CPU. This is a strong signal: defers in a hot loop.

After (helper function)¶

File: app
Type: cpu
Showing nodes accounting for 50ms, 10% of 500ms total

      flat  flat%   sum%        cum   cum%
      30ms 6.0%   6.0%       30ms 6.0%   main.processOne
      20ms 4.0%  10.0%       20ms 4.0%   sync.(*Mutex).Lock

Total drops from 500ms to ~250ms; deferproc/deferreturn no longer appear. Win.

Allocation Profile¶

go test -bench=. -benchmem -memprofile=mem.prof
go tool pprof mem.prof

If you see runtime.newdefer allocations, you have heap-path defers somewhere. Trace back to find the loop.

14. "Is It Worth Optimizing?" Guidance¶

For each defer, ask:

1. Is this function in CPU/allocation profiles? If no → leave defer alone.
2. Is the defer in a loop? If yes → fix immediately (extract helper). Easy win.
3. Does the function have ≥9 defers? If yes → consider splitting. Easy win.
4. Is the function called >1M times/sec? If yes → measure with/without defer.
5. Does removing defer create a panic-safety risk? If yes, weigh the risk against the perf gain.

In 99% of cases, the answer is "leave defer alone, it's fine".

The 1% where it matters: tight inner loops in storage engines, schedulers, allocators, query execution. Those teams know who they are.

15. Open-Coded Defer Verification¶

How to confirm a function uses the fast path:

go build -gcflags="-d=ssa/check_bce/debug=1" -o app main.go
go tool objdump -s "main\.f$" app | grep -E "deferproc|deferreturn"

If deferproc or deferreturn appears, the function is using the slow path.

If neither appears and you see your cleanup code inline before RET, the function is using open-coded defer.

For a more direct check:

go build -gcflags="-m=2" 2>&1 | grep -E "open-coded|defer"

The compiler logs which path it picked.

16. Common Optimizations Summary¶

17. Final Numbers¶

For Go 1.22, amd64, M1 single-thread (typical, varies):

If your function takes ≥1 microsecond and isn't called millions of times per second, defer overhead is invisible.

18. Summary¶

Defer's cost is small (~3-7 ns) on the open-coded fast path. It becomes meaningful (~50 ns) only when forced into the heap path: defers inside loops, or 9+ defers in a function. Measure with pprof before optimizing. The standard fixes are: extract a helper to move per-iter cleanup out of the loop; split functions to keep defer count ≤ 8; restructure to keep recover inside deferred closures only. PGO can further reduce overhead by inlining defer-using wrappers in hot paths. For 99% of code, leave defer alone.

19. References¶

• Go 1.14 release notes — open-coded defer introduction
• Keith Randall, "The cost of defer in Go 1.14" (talk)
• cmd/compile/internal/ssagen/ssa.go — open-coded codegen
• Go runtime/panic.go — runOpenDeferFrame
• Dave Cheney, pre-1.14 benchmarks of defer