Performance & Profiling

Why Performance Engineering Matters

Consider a doctor treating patients who say "I don't feel well." You could guess based on symptoms, or you could run diagnostic tests—blood work, X-rays, EKG—that show you exactly what's happening inside. Performance profiling is like those diagnostic tests for your software.

Real-World Impact:

Discord - Go migration improved performance 10x:

• Before: 30K concurrent users per server
• After: 300K concurrent users per server
• Key: CPU profiling revealed GC pressure, optimized allocations
• Result: 90% cost reduction on infrastructure

Uber - Profiling saved $1M+/year:

• pprof identified goroutine leaks in service mesh
• Memory profiling found 2GB leak per instance
• 10,000 instances × 2GB = 20TB wasted memory
• Fix: 5-line defer statement added

Cloudflare - Edge performance optimization:

• Reduced P99 latency from 200ms to 15ms
• CPU profiling revealed JSON parsing bottleneck
• Switched to faster parser, pre-allocated buffers
• Result: 13x latency improvement, 40% cost savings

Shopify - Black Friday preparation:

• Memory profiling identified 500MB leak per Ruby worker
• Migrated hot path to Go with careful profiling
• Handled 10x traffic spike without infrastructure expansion
• Result: Millions saved in cloud costs

Performance profiling separates hobby projects from production systems serving millions of requests. Go's profiling tools are among the best in any language—integrated directly into the standard library with zero external dependencies.

Learning Objectives

By the end of this article, you will master:

• Benchmarking: Write effective benchmarks to measure code performance
• CPU Profiling: Identify CPU bottlenecks using pprof and flame graphs
• Memory Profiling: Detect memory leaks and optimize allocation patterns
• Optimization Patterns: Apply proven techniques for Go performance tuning
• Production Monitoring: Implement continuous profiling for real-world applications
• Advanced Techniques: Escape analysis, compiler optimizations, and low-level tuning

Core Concepts - Understanding Performance Profiling

What is Performance Profiling?

Performance profiling is the systematic measurement of program execution to identify bottlenecks. Unlike benchmarking which measures overall performance, profiling reveals WHERE time and memory are spent within your code.

Why Go's Profiling is Superior:

1. Built into runtime - No external agents, zero config
2. Production-safe - <5% overhead, safe to run 24/7
3. Comprehensive - CPU, memory, goroutines, blocking, mutex contention
4. Visual tools - go tool pprof with interactive web UI
5. Benchmark integration - go test -bench -cpuprofile

Types of Profiling

CPU Profiling: Shows where your program spends CPU time

• Identifies hot functions and algorithms
• Reveals unexpected computation patterns
• Perfect for optimizing compute-intensive code
• Sampling-based (typically 100Hz), minimal overhead

Memory Profiling: Tracks memory allocation and usage

• Heap profiling: Shows current memory usage
• Allocation profiling: Shows where memory is allocated
• Essential for finding memory leaks
• Helps identify GC pressure

Goroutine Profiling: Tracks goroutine creation and blocking

• Identifies goroutine leaks
• Reveals concurrency bottlenecks
• Critical for high-throughput systems
• Shows goroutine stack traces

Block Profiling: Measures time goroutines spend blocked

• Channel operations
• Mutex contention
• Network I/O
• Disk I/O

Mutex Profiling: Tracks lock contention

• Identifies synchronization bottlenecks
• Shows which mutexes are contested
• Helps optimize concurrent code

The Performance Optimization Cycle

1. Measure - Profile to identify actual bottlenecks
2. Analyze - Understand why the bottleneck exists
3. Optimize - Make targeted improvements
4. Verify - Re-profile to confirm gains
5. Iterate - Repeat for next bottleneck

Golden Rule: "Premature optimization is the root of all evil" - Donald Knuth. Always profile before optimizing.

Practical Examples - Hands-On Profiling

Example 1: Writing Effective Benchmarks

Let's start with the foundation of performance work: measuring. Benchmarking is like weighing yourself before starting a diet—you need to know where you are to know if you're improving.

 1package main
 2
 3import "testing"
 4
 5func Fibonacci(n int) int {
 6    if n <= 1 {
 7        return n
 8    }
 9    return Fibonacci(n-1) + Fibonacci(n-2)
10}
11
12func BenchmarkFibonacci10(b *testing.B) {
13    for i := 0; i < b.N; i++ {
14        Fibonacci(10)
15    }
16}
17
18func BenchmarkFibonacci20(b *testing.B) {
19    for i := 0; i < b.N; i++ {
20        Fibonacci(20)
21    }
22}

Run with:

1go test -bench=. -benchmem

Understanding the output:

BenchmarkFibonacci10-8   	1000000	    1024 ns/op	  0 B/op	  0 allocs/op
BenchmarkFibonacci20-8   	    5000	   285678 ns/op	  0 B/op	  0 allocs/op

• 1000000: Number of iterations
• 1024 ns/op: Nanoseconds per operation
• 0 B/op: Bytes allocated per operation
• 0 allocs/op: Number of allocations per operation

Key Insights:

• Fibonacci(20) is 280x slower than Fibonacci(10)
• No allocations = no GC pressure
• Exponential complexity is clear from the numbers

Example 2: CPU Profiling in Action

Let's identify CPU bottlenecks in a real application:

 1package main
 2
 3import (
 4    "fmt"
 5    "os"
 6    "runtime/pprof"
 7    "time"
 8)
 9
10func expensiveOperation() {
11    sum := 0
12    for i := 0; i < 1000000; i++ {
13        sum += i * i
14    }
15}
16
17func quickOperation() {
18    time.Sleep(10 * time.Millisecond)
19}
20
21func main() {
22    // Start CPU profiling
23    f, err := os.Create("cpu.prof")
24    if err != nil {
25        panic(err)
26    }
27    defer f.Close()
28
29    pprof.StartCPUProfile(f)
30    defer pprof.StopCPUProfile()
31
32    // Simulate workload
33    for i := 0; i < 100; i++ {
34        expensiveOperation() // This will show up in profile
35        quickOperation()      // This won't
36    }
37
38    fmt.Println("Profiling complete")
39}

Analyze the profile:

1go tool pprof cpu.prof

Key pprof commands:

1top10          # Show top 10 CPU-consuming functions
2list expensiveOperation  # Show source code for function
3web            # Generate interactive flame graph

Why quickOperation doesn't appear: CPU profiling samples the call stack at fixed intervals. Functions that sleep don't consume CPU time, so they don't show up in CPU profiles. Use block profiling to catch I/O and sleep operations.

Example 3: Memory Profiling for Leak Detection

Memory leaks are silent killers in production. Here's how to find them:

 1package main
 2
 3import (
 4    "fmt"
 5    "os"
 6    "runtime"
 7    "runtime/pprof"
 8    "time"
 9)
10
11var globalLeak [][]byte
12
13func createMemory() {
14    data := make([]byte, 1024*1024) // 1MB
15    globalLeak = append(globalLeak, data) // LEAK: Never freed
16}
17
18func temporaryAllocation() {
19    data := make([]byte, 1024*1024) // 1MB
20    _ = data // This gets GC'd
21}
22
23func main() {
24    // Create some memory leaks
25    for i := 0; i < 10; i++ {
26        createMemory()
27        temporaryAllocation()
28        time.Sleep(100 * time.Millisecond)
29    }
30
31    // Force garbage collection to clean up temporary allocations
32    runtime.GC()
33
34    // Take heap snapshot
35    f, err := os.Create("heap.prof")
36    if err != nil {
37        panic(err)
38    }
39    defer f.Close()
40
41    runtime.GC() // GC before writing profile
42    if err := pprof.WriteHeapProfile(f); err != nil {
43        panic(err)
44    }
45
46    fmt.Println("Heap profile written")
47    fmt.Printf("Leaked %d MB\n", len(globalLeak))
48}

Analyze memory usage:

1go tool pprof heap.prof

Memory profile interpretation:

• alloc_objects: Total objects allocated
• inuse_objects: Currently in use
• alloc_space: Total memory allocated
• inuse_space: Currently in use

Reading the profile:

1(pprof) top
2Showing nodes accounting for 10.24MB, 100% of 10.24MB total
3      flat  flat%   sum%        cum   cum%
4   10.24MB   100%   100%    10.24MB   100%  main.createMemory

This clearly shows createMemory is responsible for the 10MB that's still in use.

Example 4: Advanced Optimization - String Concatenation

This is one of the most common performance mistakes in Go:

 1package main
 2
 3import (
 4    "bytes"
 5    "strings"
 6    "testing"
 7)
 8
 9// ❌ WRONG: Creates new string every time
10func concatWithPlus(n int) string {
11    s := ""
12    for i := 0; i < n; i++ {
13        s += "a" // New string allocation every iteration!
14    }
15    return s
16}
17
18// ✅ GOOD: Single buffer allocation
19func concatWithBuilder(n int) string {
20    var b strings.Builder
21    for i := 0; i < n; i++ {
22        b.WriteString("a")
23    }
24    return b.String()
25}
26
27// ✅ GOOD: Pre-allocated buffer
28func concatWithBuilderPrealloc(n int) string {
29    var b strings.Builder
30    b.Grow(n) // Pre-allocate exact size needed
31    for i := 0; i < n; i++ {
32        b.WriteString("a")
33    }
34    return b.String()
35}
36
37func BenchmarkConcatPlus(b *testing.B) {
38    for i := 0; i < b.N; i++ {
39        concatWithPlus(1000)
40    }
41}
42
43func BenchmarkConcatBuilder(b *testing.B) {
44    for i := 0; i < b.N; i++ {
45        concatWithBuilder(1000)
46    }
47}
48
49func BenchmarkConcatBuilderPrealloc(b *testing.B) {
50    for i := 0; i < b.N; i++ {
51        concatWithBuilderPrealloc(1000)
52    }
53}

Benchmark results:

BenchmarkConcatPlus-8              1000	   1520432 ns/op	1048576 B/op	 1000 allocs/op
BenchmarkConcatBuilder-8           2000000	     896 ns/op	   2048 B/op	     3 allocs/op
BenchmarkConcatBuilderPrealloc-8   2000000	     672 ns/op	   1024 B/op	     1 allocs/op

Results analysis:

• += operator: 1,000 allocations, 1MB memory
• strings.Builder: 3 allocations, 2KB memory
• Preallocated Builder: 1 allocation, 1KB memory
• Speedup: 2,265x faster, 1,024x less memory!

Why is += so slow? Strings in Go are immutable. Every concatenation creates a new string, copies both strings into it. This means:

• 1st iteration: copy 1 byte
• 2nd iteration: copy 2 bytes
• ...
• 1000th iteration: copy 1000 bytes
• Total: 1+2+3+...+1000 = 500,500 bytes copied!

Example 5: Slice Preallocation Optimization

 1package main
 2
 3import "testing"
 4
 5func sliceWithoutPrealloc(n int) []int {
 6    s := []int{} // Starting with zero capacity
 7    for i := 0; i < n; i++ {
 8        s = append(s, i) // Multiple allocations as slice grows
 9    }
10    return s
11}
12
13func sliceWithPrealloc(n int) []int {
14    s := make([]int, 0, n) // Pre-allocate exact capacity
15    for i := 0; i < n; i++ {
16        s = append(s, i) // No reallocation needed
17    }
18    return s
19}
20
21func BenchmarkSliceWithoutPrealloc(b *testing.B) {
22    for i := 0; i < b.N; i++ {
23        sliceWithoutPrealloc(1000)
24    }
25}
26
27func BenchmarkSliceWithPrealloc(b *testing.B) {
28    for i := 0; i < b.N; i++ {
29        sliceWithPrealloc(1000)
30    }
31}

Why preallocation matters: Without preallocation, Go doubles the slice capacity each time it runs out of space. For 1000 elements, this means ~10 allocations and copying data each time. With preallocation, you get exactly 1 allocation.

Advanced Benchmarking Techniques

Sub-Benchmarks for Comparative Analysis

 1package main
 2
 3import "testing"
 4
 5func BenchmarkProcessing(b *testing.B) {
 6    sizes := []int{10, 100, 1000, 10000}
 7
 8    for _, size := range sizes {
 9        b.Run(fmt.Sprintf("Size%d", size), func(b *testing.B) {
10            data := make([]int, size)
11            b.ResetTimer() // Don't count setup time
12
13            for i := 0; i < b.N; i++ {
14                process(data)
15            }
16        })
17    }
18}
19
20func process(data []int) {
21    for i := range data {
22        data[i] = i * 2
23    }
24}

Benefits:

• Compare performance across different input sizes
• Identify algorithmic complexity
• Clear performance characteristics

Parallel Benchmarks

1func BenchmarkParallel(b *testing.B) {
2    b.RunParallel(func(pb *testing.PB) {
3        for pb.Next() {
4            // This runs in parallel across multiple goroutines
5            compute()
6        }
7    })
8}

Use for:

• Testing concurrent data structures
• Measuring lock contention
• Evaluating scalability

Benchmarking with Setup and Teardown

 1func BenchmarkDatabaseOperation(b *testing.B) {
 2    // Setup: runs once
 3    db := setupTestDatabase()
 4    defer db.Close()
 5
 6    b.ResetTimer() // Don't count setup time
 7
 8    for i := 0; i < b.N; i++ {
 9        b.StopTimer()  // Don't count test data preparation
10        testData := generateTestData()
11        b.StartTimer() // Resume timing
12
13        db.Insert(testData)
14    }
15}

Common Patterns and Pitfalls

Pattern 1: HTTP Server Profiling

 1package main
 2
 3import (
 4    "fmt"
 5    "log"
 6    "net/http"
 7    _ "net/http/pprof" // Import for side effects
 8)
 9
10func slowHandler(w http.ResponseWriter, r *http.Request) {
11    sum := 0
12    for i := 0; i < 10000000; i++ {
13        sum += i // CPU intensive work
14    }
15    fmt.Fprintf(w, "Sum: %d", sum)
16}
17
18func fastHandler(w http.ResponseWriter, r *http.Request) {
19    fmt.Fprint(w, "Quick response")
20}
21
22func main() {
23    http.HandleFunc("/slow", slowHandler)
24    http.HandleFunc("/fast", fastHandler)
25
26    // pprof endpoints automatically registered:
27    // /debug/pprof/
28    // /debug/pprof/profile
29    // /debug/pprof/heap
30    // /debug/pprof/goroutine
31
32    log.Println("Server with profiling on :8080")
33    log.Fatal(http.ListenAndServe(":8080", nil))
34}

Access profiles:

1# Get 30-second CPU profile
2curl http://localhost:8080/debug/pprof/profile?seconds=30 > cpu.prof
3
4# Get current heap snapshot
5curl http://localhost:8080/debug/pprof/heap > heap.prof
6
7# Get goroutine snapshot
8curl http://localhost:8080/debug/pprof/goroutine > goroutine.prof

Pattern 2: Production-Ready Continuous Profiling

  1package main
  2
  3import (
  4	"context"
  5	"fmt"
  6	"log"
  7	"net/http"
  8	_ "net/http/pprof"
  9	"os"
 10	"runtime"
 11	"runtime/pprof"
 12	"time"
 13)
 14
 15// ContinuousProfiler collects profiles periodically
 16type ContinuousProfiler struct {
 17	outputDir string
 18	interval  time.Duration
 19	ctx       context.Context
 20	cancel    context.CancelFunc
 21}
 22
 23func NewContinuousProfiler(outputDir string, interval time.Duration) *ContinuousProfiler {
 24	ctx, cancel := context.WithCancel(context.Background())
 25	return &ContinuousProfiler{
 26		outputDir: outputDir,
 27		interval:  interval,
 28		ctx:       ctx,
 29		cancel:    cancel,
 30	}
 31}
 32
 33func (cp *ContinuousProfiler) Start() {
 34	os.MkdirAll(cp.outputDir, 0755)
 35
 36	go cp.collectCPUProfiles()
 37	go cp.collectMemProfiles()
 38	go cp.collectGoroutineProfiles()
 39}
 40
 41func (cp *ContinuousProfiler) collectCPUProfiles() {
 42	ticker := time.NewTicker(cp.interval)
 43	defer ticker.Stop()
 44
 45	for {
 46		select {
 47		case <-cp.ctx.Done():
 48			return
 49		case t := <-ticker.C:
 50			filename := fmt.Sprintf("%s/cpu_%s.prof", cp.outputDir, t.Format("20060102_150405"))
 51			f, err := os.Create(filename)
 52			if err != nil {
 53				log.Printf("Failed to create CPU profile: %v", err)
 54				continue
 55			}
 56
 57			pprof.StartCPUProfile(f)
 58			time.Sleep(30 * time.Second) // Profile for 30 seconds
 59			pprof.StopCPUProfile()
 60			f.Close()
 61
 62			log.Printf("CPU profile saved: %s", filename)
 63		}
 64	}
 65}
 66
 67func (cp *ContinuousProfiler) collectMemProfiles() {
 68	ticker := time.NewTicker(cp.interval * 2) // Less frequent
 69	defer ticker.Stop()
 70
 71	for {
 72		select {
 73		case <-cp.ctx.Done():
 74			return
 75		case t := <-ticker.C:
 76			runtime.GC() // Get accurate heap stats
 77
 78			filename := fmt.Sprintf("%s/mem_%s.prof", cp.outputDir, t.Format("20060102_150405"))
 79			f, err := os.Create(filename)
 80			if err != nil {
 81				log.Printf("Failed to create memory profile: %v", err)
 82				continue
 83			}
 84
 85			pprof.WriteHeapProfile(f)
 86			f.Close()
 87
 88			log.Printf("Memory profile saved: %s", filename)
 89		}
 90	}
 91}
 92
 93func (cp *ContinuousProfiler) collectGoroutineProfiles() {
 94	ticker := time.NewTicker(cp.interval)
 95	defer ticker.Stop()
 96
 97	for {
 98		select {
 99		case <-cp.ctx.Done():
100			return
101		case t := <-ticker.C:
102			filename := fmt.Sprintf("%s/goroutine_%s.prof", cp.outputDir, t.Format("20060102_150405"))
103			f, err := os.Create(filename)
104			if err != nil {
105				log.Printf("Failed to create goroutine profile: %v", err)
106				continue
107			}
108
109			pprof.Lookup("goroutine").WriteTo(f, 0)
110			f.Close()
111
112			log.Printf("Goroutine profile saved: %s", filename)
113		}
114	}
115}
116
117func (cp *ContinuousProfiler) Stop() {
118	cp.cancel()
119}
120
121func main() {
122	// Start continuous profiler
123	profiler := NewContinuousProfiler("./profiles", 5*time.Minute)
124	profiler.Start()
125	defer profiler.Stop()
126
127	// Start HTTP server with pprof endpoints
128	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
129		w.Write([]byte("Server running with continuous profiling"))
130	})
131
132	log.Println("Server with continuous profiling on :8080")
133	log.Fatal(http.ListenAndServe(":8080", nil))
134}

Common Pitfalls and How to Avoid Them

Pitfall 1: Optimizing Without Measuring

Wrong approach:

1// Don't optimize based on assumptions!
2func processData(data []int) []int {
3    // This "optimization" might actually be slower
4    result := make([]int, len(data))
5    for i := range data {
6        result[i] = data[i] * 2
7    }
8    return result
9}

Right approach:

1// Profile first, then optimize hot paths
2func processData(data []int) []int {
3    // Simple implementation first
4    result := make([]int, len(data))
5    for i, v := range data {
6        result[i] = v * 2
7    }
8    return result
9}

Pitfall 2: Premature Micro-optimizations

Remember:

• Profile before optimizing
• Focus on algorithms, not micro-optimizations
• 80% of time is spent in 20% of code
• Use strings.Builder instead of += for concatenation
• Preallocate slices when size is known

Pitfall 3: Ignoring Memory Allocation Patterns

 1// ❌ BAD: Excessive allocations
 2func processItems(items []string) string {
 3    var result string
 4    for _, item := range items {
 5        result += item + "," // New allocation every time
 6    }
 7    return result
 8}
 9
10// ✅ GOOD: Minimal allocations
11func processItems(items []string) string {
12    var b strings.Builder
13    b.Grow(len(items) * 10) // Estimate size
14    for i, item := range items {
15        if i > 0 {
16            b.WriteString(",")
17        }
18        b.WriteString(item)
19    }
20    return b.String()
21}

Integration and Mastery - Advanced Techniques

Technique 1: Flame Graph Visualization

Flame graphs provide intuitive visualization of CPU usage:

1# Generate CPU profile
2go tool pprof -http=:8080 cpu.prof
3# Opens browser with interactive flame graph

Reading flame graphs:

• Width: Time spent in function
• Height: Call stack depth
• Color: Random (for visual separation)
• Click to zoom: Focus on specific subtrees

What to look for:

• Wide bars = hot functions (optimize these)
• Tall stacks = deep call chains (may indicate recursion)
• Plateaus = opportunities for optimization

Technique 2: Comparative Profiling

Compare performance before and after optimizations:

 1# Generate baseline profile
 2go test -bench=. -cpuprofile=old.prof
 3
 4# Make optimizations...
 5
 6# Generate new profile
 7go test -bench=. -cpuprofile=new.prof
 8
 9# Compare the profiles
10go tool pprof -base old.prof new.prof

Technique 3: Goroutine Leak Detection

 1package main
 2
 3import (
 4    "fmt"
 5    "runtime"
 6    "time"
 7)
 8
 9func goroutineLeak() {
10    ch := make(chan int)
11    go func() {
12        // This goroutine never exits - blocks on channel read
13        <-ch
14    }()
15    // Channel never written to, goroutine leaks
16}
17
18func main() {
19    fmt.Printf("Starting goroutines: %d\n", runtime.NumGoroutine())
20
21    for i := 0; i < 100; i++ {
22        goroutineLeak()
23    }
24
25    // Check goroutine count
26    time.Sleep(1 * time.Second)
27    fmt.Printf("Goroutines after leaks: %d\n", runtime.NumGoroutine())
28}

Profile to detect leaks:

1go tool pprof http://localhost:8080/debug/pprof/goroutine

Technique 4: Escape Analysis

Escape analysis determines whether variables can be stack-allocated (fast) or must be heap-allocated (slower, requires GC).

 1package main
 2
 3func stackAllocated() int {
 4    x := 42 // Stays on stack
 5    return x
 6}
 7
 8func heapAllocated() *int {
 9    x := 42 // Escapes to heap (pointer returned)
10    return &x
11}
12
13func main() {
14    stackAllocated()
15    heapAllocated()
16}

Check escape analysis:

1go build -gcflags="-m" main.go

Output:

./main.go:8:2: moved to heap: x

Optimization opportunities:

• Avoid returning pointers when possible
• Use value receivers instead of pointer receivers for small structs
• Be aware of interface conversions (they can cause allocations)

Technique 5: Compiler Optimization Flags

 1# Default optimization
 2go build -o binary main.go
 3
 4# Disable inlining (for debugging)
 5go build -gcflags="-l" -o binary main.go
 6
 7# More aggressive optimization (can increase binary size)
 8go build -ldflags="-s -w" -o binary main.go
 9
10# Print optimization decisions
11go build -gcflags="-m -m" main.go

Flags explained:

• -s: Omit symbol table
• -w: Omit DWARF debug info
• -l: Disable inlining
• -m: Print optimization decisions

Technique 6: Using sync.Pool for Object Reuse

 1package main
 2
 3import (
 4    "bytes"
 5    "sync"
 6)
 7
 8var bufferPool = sync.Pool{
 9    New: func() interface{} {
10        return new(bytes.Buffer)
11    },
12}
13
14func processData(data []byte) []byte {
15    // Get buffer from pool
16    buf := bufferPool.Get().(*bytes.Buffer)
17    defer bufferPool.Put(buf)
18
19    buf.Reset() // Clear buffer
20    buf.Write(data)
21
22    // Process...
23
24    return buf.Bytes()
25}

When to use sync.Pool:

• Frequently allocated objects
• Objects that can be reused
• High-frequency operations
• Want to reduce GC pressure

When NOT to use:

• Long-lived objects
• Objects that shouldn't be shared
• When memory usage is already low

Performance Optimization Patterns

Pattern 1: Reduce Allocations with Buffering

 1// ❌ BAD: Many small allocations
 2func readLines(r io.Reader) ([]string, error) {
 3    var lines []string
 4    scanner := bufio.NewScanner(r)
 5    for scanner.Scan() {
 6        lines = append(lines, scanner.Text()) // Allocation per line
 7    }
 8    return lines, scanner.Err()
 9}
10
11// ✅ GOOD: Pre-allocated buffer
12func readLines(r io.Reader) ([]string, error) {
13    lines := make([]string, 0, 100) // Pre-allocate
14    scanner := bufio.NewScanner(r)
15    for scanner.Scan() {
16        lines = append(lines, scanner.Text())
17    }
18    return lines, scanner.Err()
19}

Pattern 2: Use Byte Slices Instead of Strings

 1// ❌ BAD: String concatenation
 2func processLog(entries []string) string {
 3    result := ""
 4    for _, entry := range entries {
 5        result += entry + "\n"
 6    }
 7    return result
 8}
 9
10// ✅ GOOD: Byte slice operations
11func processLog(entries []string) []byte {
12    var buf bytes.Buffer
13    for _, entry := range entries {
14        buf.WriteString(entry)
15        buf.WriteByte('\n')
16    }
17    return buf.Bytes()
18}

Pattern 3: Optimize Map Access

 1// ❌ BAD: Multiple map lookups
 2func getValue(m map[string]int, key string) int {
 3    if _, exists := m[key]; exists {
 4        return m[key] // Second lookup
 5    }
 6    return 0
 7}
 8
 9// ✅ GOOD: Single lookup
10func getValue(m map[string]int, key string) int {
11    if val, exists := m[key]; exists {
12        return val // Use cached value
13    }
14    return 0
15}

Pattern 4: Minimize Interface Conversions

 1// ❌ BAD: Interface conversion in hot path
 2func sum(items []interface{}) int {
 3    total := 0
 4    for _, item := range items {
 5        total += item.(int) // Type assertion per iteration
 6    }
 7    return total
 8}
 9
10// ✅ GOOD: Concrete type
11func sum(items []int) int {
12    total := 0
13    for _, item := range items {
14        total += item // No conversion needed
15    }
16    return total
17}

Pattern 5: Struct Field Alignment

 1// ❌ BAD: Poor alignment (24 bytes on 64-bit)
 2type BadStruct struct {
 3    a bool   // 1 byte + 7 bytes padding
 4    b int64  // 8 bytes
 5    c bool   // 1 byte + 7 bytes padding
 6}
 7
 8// ✅ GOOD: Optimized alignment (16 bytes on 64-bit)
 9type GoodStruct struct {
10    b int64  // 8 bytes
11    a bool   // 1 byte
12    c bool   // 1 byte + 6 bytes padding
13}

Check struct size:

1import "unsafe"
2fmt.Println(unsafe.Sizeof(BadStruct{}))  // 24
3fmt.Println(unsafe.Sizeof(GoodStruct{})) // 16

Performance Optimization Checklist

Before Optimizing

• Profile application under realistic load
• Identify actual bottlenecks, not perceived ones
• Set measurable performance goals
• Establish baseline metrics

Common Optimizations

• Use strings.Builder for string concatenation
• Preallocate slices and maps when size is known
• Use sync.Pool for object reuse
• Minimize interface{} usage in hot paths
• Avoid allocations in loops
• Use buffered I/O for file operations

Advanced Techniques

• Implement connection pooling
• Use efficient data structures
• Consider cache-friendly algorithms
• Implement proper concurrency patterns
• Use CPU affinity if applicable

After Optimizing

• Re-profile to verify improvements
• Run comprehensive tests
• Monitor in production
• Document optimizations and trade-offs

Practice Exercises

Exercise 1: Optimize String Building

Difficulty: Intermediate | Time: 20-25 minutes

Learning Objectives:

• Master string concatenation performance techniques
• Understand memory allocation patterns in Go
• Practice using strings.Builder for efficient string operations

Real-World Context:
String building optimization is crucial in many applications. It's used in template engines for HTML generation, in logging systems for message formatting, in data export systems for CSV/JSON generation, and in API responses for building complex payloads. Understanding string concatenation performance will help you avoid common pitfalls that can cause significant performance degradation in string-heavy applications.

Task:
Optimize a function that builds a large string by identifying performance bottlenecks in string concatenation and implementing efficient alternatives like strings.Builder with proper buffer management.

 1package main
 2
 3import (
 4    "strings"
 5    "testing"
 6)
 7
 8// Slow: string concatenation
 9func buildStringSlow(n int) string {
10    s := ""
11    for i := 0; i < n; i++ {
12        s += "line " + string(rune(i)) + "\n"
13    }
14    return s
15}
16
17// Fast: strings.Builder
18func buildStringFast(n int) string {
19    var b strings.Builder
20    b.Grow(n * 10) // Preallocate approximate size
21
22    for i := 0; i < n; i++ {
23        b.WriteString("line ")
24        b.WriteRune(rune(i))
25        b.WriteString("\n")
26    }
27    return b.String()
28}
29
30func BenchmarkBuildStringSlow(b *testing.B) {
31    for i := 0; i < b.N; i++ {
32        buildStringSlow(100)
33    }
34}
35
36func BenchmarkBuildStringFast(b *testing.B) {
37    for i := 0; i < b.N; i++ {
38        buildStringFast(100)
39    }
40}

Exercise 2: Profile Memory Usage

Difficulty: Advanced | Time: 30-35 minutes

Learning Objectives:

• Master memory profiling with pprof
• Understand memory allocation patterns and garbage collection
• Practice identifying and fixing memory leaks

Real-World Context:
Memory profiling is essential for building production applications. It's used in web services to prevent memory leaks, in data processing pipelines to optimize memory usage, in microservices to maintain performance under load, and in long-running applications to ensure stability. Understanding memory optimization will help you build applications that can run reliably for extended periods without memory-related issues.

Task:
Create a program that allocates memory inefficiently and optimize it by using memory profiling tools to identify allocation hotspots, implementing object pooling, reducing unnecessary allocations, and improving garbage collection efficiency.

 1package main
 2
 3import (
 4    "fmt"
 5    "testing"
 6)
 7
 8type User struct {
 9    ID       int
10    Name     string
11    Email    string
12    Settings map[string]string
13}
14
15// Inefficient: lots of small allocations
16func createUsersSlow(n int) []*User {
17    users := []*User{}
18    for i := 0; i < n; i++ {
19        user := &User{
20            ID:    i,
21            Name:  fmt.Sprintf("User%d", i),
22            Email: fmt.Sprintf("user%d@example.com", i),
23            Settings: map[string]string{
24                "theme": "dark",
25            },
26        }
27        users = append(users, user)
28    }
29    return users
30}
31
32// Optimized: preallocate slices and maps
33func createUsersFast(n int) []*User {
34    users := make([]*User, 0, n)
35    for i := 0; i < n; i++ {
36        settings := make(map[string]string, 1)
37        settings["theme"] = "dark"
38
39        user := &User{
40            ID:       i,
41            Name:     fmt.Sprintf("User%d", i),
42            Email:    fmt.Sprintf("user%d@example.com", i),
43            Settings: settings,
44        }
45        users = append(users, user)
46    }
47    return users
48}
49
50func BenchmarkCreateUsersSlow(b *testing.B) {
51    for i := 0; i < b.N; i++ {
52        createUsersSlow(1000)
53    }
54}
55
56func BenchmarkCreateUsersFast(b *testing.B) {
57    for i := 0; i < b.N; i++ {
58        createUsersFast(1000)
59    }
60}

Exercise 3: Concurrent Map Access

Difficulty: Advanced | Time: 30-35 minutes

Learning Objectives:

• Master concurrent programming patterns and synchronization
• Understand map performance under concurrent access
• Practice implementing lock-free data structures

Real-World Context:
Concurrent map optimization is critical in high-performance systems. It's used in caching systems for fast data lookup, in rate limiting implementations for tracking request counts, in session management for user data storage, and in real-time analytics for metric aggregation. Understanding concurrent data structures will help you build systems that can handle high concurrency without becoming bottlenecks.

Task:
Optimize concurrent map access using different techniques like sync.Map, sharding with mutexes, and atomic operations to minimize contention while maintaining data consistency and thread safety in high-throughput scenarios.

 1package main
 2
 3import (
 4    "sync"
 5    "testing"
 6)
 7
 8// Using mutex
 9type MutexMap struct {
10    mu   sync.RWMutex
11    data map[string]int
12}
13
14func NewMutexMap() *MutexMap {
15    return &MutexMap{
16        data: make(map[string]int),
17    }
18}
19
20func (m *MutexMap) Set(key string, value int) {
21    m.mu.Lock()
22    m.data[key] = value
23    m.mu.Unlock()
24}
25
26func (m *MutexMap) Get(key string) (int, bool) {
27    m.mu.RLock()
28    val, ok := m.data[key]
29    m.mu.RUnlock()
30    return val, ok
31}
32
33// Using sync.Map
34type SyncMapWrapper struct {
35    data sync.Map
36}
37
38func NewSyncMap() *SyncMapWrapper {
39    return &SyncMapWrapper{}
40}
41
42func (s *SyncMapWrapper) Set(key string, value int) {
43    s.data.Store(key, value)
44}
45
46func (s *SyncMapWrapper) Get(key string) (int, bool) {
47    val, ok := s.data.Load(key)
48    if !ok {
49        return 0, false
50    }
51    return val.(int), true
52}
53
54func BenchmarkMutexMap(b *testing.B) {
55    m := NewMutexMap()
56
57    b.RunParallel(func(pb *testing.PB) {
58        for pb.Next() {
59            m.Set("key", 42)
60            m.Get("key")
61        }
62    })
63}
64
65func BenchmarkSyncMap(b *testing.B) {
66    m := NewSyncMap()
67
68    b.RunParallel(func(pb *testing.PB) {
69        for pb.Next() {
70            m.Set("key", 42)
71            m.Get("key")
72        }
73    })
74}

Exercise 4: CPU-Bound Task Optimization

Difficulty: Advanced | Time: 35-40 minutes

Learning Objectives:

• Master parallel processing with worker pools
• Understand CPU-bound vs I/O-bound optimization strategies
• Practice implementing efficient concurrent algorithms

Real-World Context:
CPU-bound task optimization is essential in compute-intensive applications. It's used in image processing services for photo manipulation, in video encoding platforms for transcoding, in machine learning pipelines for data processing, and in scientific computing for numerical simulations. Understanding parallel processing will help you build applications that can fully utilize multi-core systems for maximum performance.

Task:
Implement a parallel image processing pipeline that processes images concurrently using worker pools, demonstrating performance improvement over sequential processing through proper workload distribution and resource management.

  1package main
  2
  3import (
  4	"fmt"
  5	"image"
  6	"image/color"
  7	"image/png"
  8	"os"
  9	"runtime"
 10	"sync"
 11	"time"
 12)
 13
 14// ImageProcessor applies filters to images
 15type ImageProcessor struct {
 16	workers int
 17}
 18
 19func NewImageProcessor(workers int) *ImageProcessor {
 20	if workers <= 0 {
 21		workers = runtime.NumCPU()
 22	}
 23	return &ImageProcessor{workers: workers}
 24}
 25
 26// ProcessSequential processes images one by one
 27func (ip *ImageProcessor) ProcessSequential(images []*image.RGBA) []*image.RGBA {
 28	results := make([]*image.RGBA, len(images))
 29	for i, img := range images {
 30		results[i] = applyGrayscaleFilter(img)
 31	}
 32	return results
 33}
 34
 35// ProcessParallel processes images using worker pool
 36func (ip *ImageProcessor) ProcessParallel(images []*image.RGBA) []*image.RGBA {
 37	results := make([]*image.RGBA, len(images))
 38	jobs := make(chan int, len(images))
 39	var wg sync.WaitGroup
 40
 41	// Start workers
 42	for w := 0; w < ip.workers; w++ {
 43		wg.Add(1)
 44		go func() {
 45			defer wg.Done()
 46			for idx := range jobs {
 47				results[idx] = applyGrayscaleFilter(images[idx])
 48			}
 49		}()
 50	}
 51
 52	// Send jobs
 53	for i := range images {
 54		jobs <- i
 55	}
 56	close(jobs)
 57
 58	wg.Wait()
 59	return results
 60}
 61
 62// applyGrayscaleFilter converts image to grayscale
 63func applyGrayscaleFilter(img *image.RGBA) *image.RGBA {
 64	bounds := img.Bounds()
 65	result := image.NewRGBA(bounds)
 66
 67	for y := bounds.Min.Y; y < bounds.Max.Y; y++ {
 68		for x := bounds.Min.X; x < bounds.Max.X; x++ {
 69			r, g, b, a := img.At(x, y).RGBA()
 70
 71			// Convert to grayscale
 72			gray := uint8((r + g + b) / 3 >> 8)
 73			result.Set(x, y, color.RGBA{gray, gray, gray, uint8(a >> 8)})
 74		}
 75	}
 76
 77	return result
 78}
 79
 80// generateTestImage creates a test image
 81func generateTestImage(width, height int) *image.RGBA {
 82	img := image.NewRGBA(image.Rect(0, 0, width, height))
 83
 84	for y := 0; y < height; y++ {
 85		for x := 0; x < width; x++ {
 86			// Create gradient pattern
 87			r := uint8((x * 255) / width)
 88			g := uint8((y * 255) / height)
 89			b := uint8(((x + y) * 255) / (width + height))
 90			img.Set(x, y, color.RGBA{r, g, b, 255})
 91		}
 92	}
 93
 94	return img
 95}
 96
 97// benchmark runs a benchmark
 98func benchmark(name string, fn func()) time.Duration {
 99	start := time.Now()
100	fn()
101	duration := time.Since(start)
102	fmt.Printf("%s: %v\n", name, duration)
103	return duration
104}
105
106func main() {
107	// Generate test images
108	fmt.Println("Generating test images...")
109	numImages := 20
110	imageSize := 500
111	images := make([]*image.RGBA, numImages)
112	for i := 0; i < numImages; i++ {
113		images[i] = generateTestImage(imageSize, imageSize)
114	}
115
116	fmt.Printf("\nProcessing %d images (%dx%d)\n", numImages, imageSize, imageSize)
117	fmt.Printf("CPU cores: %d\n\n", runtime.NumCPU())
118
119	processor := NewImageProcessor(runtime.NumCPU())
120
121	// Benchmark sequential processing
122	var seqResults []*image.RGBA
123	seqTime := benchmark("Sequential", func() {
124		seqResults = processor.ProcessSequential(images)
125	})
126
127	// Benchmark parallel processing
128	var parResults []*image.RGBA
129	parTime := benchmark("Parallel", func() {
130		parResults = processor.ProcessParallel(images)
131	})
132
133	// Calculate speedup
134	fmt.Printf("\nSpeedup:\n")
135	fmt.Printf("  Parallel vs Sequential: %.2fx faster\n", float64(seqTime)/float64(parTime))
136
137	// Verify results
138	fmt.Printf("\nProcessed %d images successfully\n", len(seqResults))
139
140	// Optional: Save sample output
141	if len(parResults) > 0 {
142		saveImage("output_parallel.png", parResults[0])
143		fmt.Println("Saved sample output to output_parallel.png")
144	}
145}
146
147func saveImage(filename string, img *image.RGBA) error {
148	f, err := os.Create(filename)
149	if err != nil {
150		return err
151	}
152	defer f.Close()
153	return png.Encode(f, img)
154}

Generating test images...

Processing 20 images (500x500)
CPU cores: 8

Sequential: 1.234s
Parallel: 185ms

Speedup:
  Parallel vs Sequential: 6.67x faster

Processed 20 images successfully
Saved sample output to output_parallel.png

Exercise 5: I/O-Bound Task Optimization

Difficulty: Expert | Time: 40-45 minutes

Learning Objectives:

• Master I/O-bound task optimization strategies
• Understand concurrent file processing and buffering
• Practice implementing high-throughput data processing pipelines

Real-World Context:
I/O optimization is critical for data-intensive applications. It's used in log analysis systems for processing massive log files, in data ingestion pipelines for handling file uploads, in backup systems for efficient file transfers, and in ETL processes for data transformation. Understanding I/O optimization will help you build systems that can handle large-scale data processing efficiently.

Task:
Implement a high-performance log aggregator that reads multiple large log files concurrently, uses buffering, and batch processes entries for maximum throughput while managing memory usage and error handling effectively.

  1package main
  2
  3import (
  4	"bufio"
  5	"fmt"
  6	"io"
  7	"os"
  8	"strings"
  9	"sync"
 10	"time"
 11)
 12
 13// LogEntry represents a parsed log entry
 14type LogEntry struct {
 15	Timestamp time.Time
 16	Level     string
 17	Message   string
 18	Source    string
 19}
 20
 21// LogAggregator processes log files efficiently
 22type LogAggregator struct {
 23	batchSize   int
 24	workers     int
 25	bufferSize  int
 26	entries     chan LogEntry
 27	batches     chan []LogEntry
 28	mu          sync.Mutex
 29	stats       Stats
 30}
 31
 32type Stats struct {
 33	FilesProcessed int
 34	LinesProcessed int
 35	Errors         int
 36	Duration       time.Duration
 37}
 38
 39func NewLogAggregator(workers, batchSize, bufferSize int) *LogAggregator {
 40	return &LogAggregator{
 41		batchSize:  batchSize,
 42		workers:    workers,
 43		bufferSize: bufferSize,
 44		entries:    make(chan LogEntry, bufferSize),
 45		batches:    make(chan []LogEntry, workers),
 46	}
 47}
 48
 49// ProcessFiles processes multiple log files concurrently
 50func (la *LogAggregator) ProcessFiles(filenames []string) ([]LogEntry, error) {
 51	start := time.Now()
 52	defer func() {
 53		la.mu.Lock()
 54		la.stats.Duration = time.Since(start)
 55		la.mu.Unlock()
 56	}()
 57
 58	// Start batch processor
 59	var wg sync.WaitGroup
 60	wg.Add(1)
 61	go la.batchProcessor(&wg)
 62
 63	// Process files concurrently
 64	var fileWg sync.WaitGroup
 65	for _, filename := range filenames {
 66		fileWg.Add(1)
 67		go func(fn string) {
 68			defer fileWg.Done()
 69			if err := la.processFile(fn); err != nil {
 70				la.mu.Lock()
 71				la.stats.Errors++
 72				la.mu.Unlock()
 73				fmt.Printf("Error processing %s: %v\n", fn, err)
 74			}
 75		}(filename)
 76	}
 77
 78	// Wait for all files to be processed
 79	fileWg.Wait()
 80	close(la.entries)
 81
 82	// Wait for batch processor to finish
 83	wg.Wait()
 84
 85	// Collect all batches
 86	var allEntries []LogEntry
 87	for batch := range la.batches {
 88		allEntries = append(allEntries, batch...)
 89	}
 90
 91	return allEntries, nil
 92}
 93
 94// processFile reads and parses a single log file with buffering
 95func (la *LogAggregator) processFile(filename string) error {
 96	file, err := os.Open(filename)
 97	if err != nil {
 98		return err
 99	}
100	defer file.Close()
101
102	// Use buffered reader for efficient I/O
103	reader := bufio.NewReaderSize(file, la.bufferSize)
104	lineCount := 0
105
106	for {
107		line, err := reader.ReadString('\n')
108		if err != nil {
109			if err == io.EOF {
110				break
111			}
112			return err
113		}
114
115		lineCount++
116
117		// Parse log entry
118		if entry, ok := la.parseLine(line, filename); ok {
119			la.entries <- entry
120		}
121	}
122
123	la.mu.Lock()
124	la.stats.FilesProcessed++
125	la.stats.LinesProcessed += lineCount
126	la.mu.Unlock()
127
128	return nil
129}
130
131// parseLine parses a log line into a LogEntry
132func (la *LogAggregator) parseLine(line, source string) (LogEntry, bool) {
133	// Simple parser: [timestamp] [level] message
134	// Example: 2024-01-15 10:30:00 INFO Server started
135
136	parts := strings.Fields(line)
137	if len(parts) < 4 {
138		return LogEntry{}, false
139	}
140
141	timestamp, err := time.Parse("2006-01-02 15:04:05", parts[0]+" "+parts[1])
142	if err != nil {
143		return LogEntry{}, false
144	}
145
146	return LogEntry{
147		Timestamp: timestamp,
148		Level:     parts[2],
149		Message:   strings.Join(parts[3:], " "),
150		Source:    source,
151	}, true
152}
153
154// batchProcessor batches log entries for efficient processing
155func (la *LogAggregator) batchProcessor(wg *sync.WaitGroup) {
156	defer wg.Done()
157	defer close(la.batches)
158
159	batch := make([]LogEntry, 0, la.batchSize)
160
161	for entry := range la.entries {
162		batch = append(batch, entry)
163
164		if len(batch) >= la.batchSize {
165			// Send batch
166			la.batches <- batch
167			// Create new batch
168			batch = make([]LogEntry, 0, la.batchSize)
169		}
170	}
171
172	// Send remaining entries
173	if len(batch) > 0 {
174		la.batches <- batch
175	}
176}
177
178// Stats returns processing statistics
179func (la *LogAggregator) Stats() Stats {
180	la.mu.Lock()
181	defer la.mu.Unlock()
182	return la.stats
183}
184
185// generateTestLogFile creates a test log file
186func generateTestLogFile(filename string, lines int) error {
187	file, err := os.Create(filename)
188	if err != nil {
189		return err
190	}
191	defer file.Close()
192
193	// Use buffered writer for efficient writing
194	writer := bufio.NewWriter(file)
195	defer writer.Flush()
196
197	levels := []string{"INFO", "WARN", "ERROR", "DEBUG"}
198	messages := []string{
199		"Server started successfully",
200		"Database connection established",
201		"Request processed",
202		"Cache miss",
203		"User authenticated",
204	}
205
206	baseTime := time.Now()
207
208	for i := 0; i < lines; i++ {
209		timestamp := baseTime.Add(time.Duration(i) * time.Second)
210		level := levels[i%len(levels)]
211		message := messages[i%len(messages)]
212
213		line := fmt.Sprintf("%s %s %s\n",
214			timestamp.Format("2006-01-02 15:04:05"),
215			level,
216			message,
217		)
218
219		if _, err := writer.WriteString(line); err != nil {
220			return err
221		}
222	}
223
224	return nil
225}
226
227func main() {
228	// Generate test log files
229	fmt.Println("Generating test log files...")
230	numFiles := 10
231	linesPerFile := 10000
232	filenames := make([]string, numFiles)
233
234	for i := 0; i < numFiles; i++ {
235		filename := fmt.Sprintf("test_log_%d.txt", i)
236		filenames[i] = filename
237
238		if err := generateTestLogFile(filename, linesPerFile); err != nil {
239			fmt.Printf("Error generating %s: %v\n", filename, err)
240			return
241		}
242	}
243
244	fmt.Printf("Generated %d log files with %d lines each\n\n", numFiles, linesPerFile)
245
246	// Test different configurations
247	configs := []struct {
248		name       string
249		workers    int
250		batchSize  int
251		bufferSize int
252	}{
253		{"Sequential", 1, 100, 4096},
254		{"Parallel", 4, 500, 8192},
255		{"Optimized", 8, 1000, 16384},
256	}
257
258	for _, config := range configs {
259		fmt.Printf("=== %s ===\n", config.name)
260
261		aggregator := NewLogAggregator(config.workers, config.batchSize, config.bufferSize)
262
263		start := time.Now()
264		entries, err := aggregator.ProcessFiles(filenames)
265		duration := time.Since(start)
266
267		if err != nil {
268			fmt.Printf("Error: %v\n", err)
269			continue
270		}
271
272		stats := aggregator.Stats()
273
274		fmt.Printf("Processed: %d files, %d lines, %d entries\n",
275			stats.FilesProcessed, stats.LinesProcessed, len(entries))
276		fmt.Printf("Duration: %v\n", duration)
277		fmt.Printf("Throughput: %.0f lines/sec\n", float64(stats.LinesProcessed)/duration.Seconds())
278		fmt.Printf("Errors: %d\n\n", stats.Errors)
279	}
280
281	// Cleanup
282	fmt.Println("Cleaning up test files...")
283	for _, filename := range filenames {
284		os.Remove(filename)
285	}
286}