Slice vs Map Performance in Golang

When searching for values in Go, developers often face a choice: use slices.Contains for linear search or perform a map lookup. This article benchmarks both approaches across different dataset sizes to help you make informed decisions.

Benchmark Setup

The benchmarks compare two primary approaches for finding values:

1. slices.Contains: Linear iteration through a slice checking for exact element match
2. Map Lookup: Direct key lookup in a map[string]bool

All benchmarks were run on an Apple M3 Pro processor using Go’s built-in testing framework. Dataset sizes tested: 10, 100, 1K, 10K, 100K, 500K, 1M, and 10M elements.

Results

Search Performance

Key Findings:

• slices.Contains performs exact element matching with O(n) complexity
• Average time per element check: ~4.5 ns/op
• Map lookup remains constant at O(1): ~16 ns/op regardless of size
• At 10M elements, slice search takes 45.3ms while map lookup stays at ~16ns

Memory Allocation

Both approaches show zero allocations during lookup operations, as the data structures are pre-allocated.

Analysis

Performance Characteristics

Map Lookup: O(1) constant time complexity

• Consistently performs at ~16 ns/op regardless of dataset size
• Ideal for lookups in large datasets
• Requires more memory upfront for hash table storage

slices.Contains: O(n) linear time complexity

• Performance degrades linearly with dataset size
• For 1M elements: ~4.53ms (~286,000x slower than map)
• For 10M elements: ~45.3ms (~2,860,000x slower than map)
• Average check per element: ~4.5 ns/op
• Memory efficient for small datasets but performance penalty is severe at scale

Crossover Point

For datasets with fewer than 10 elements, the performance difference is minimal (~45 ns vs ~16 ns). However, maps still outperform slices even at this small scale. The real performance gap becomes apparent with 100+ elements.

When to Use Each

Use Map when:

• Dataset size > 10 elements
• Frequent lookups are required
• Performance is critical
• Memory overhead is acceptable

Use Slice when:

• Dataset is very small (< 5 elements)
• Memory is extremely constrained
• Data structure is temporary
• Order preservation is required

Concurrent Access Performance

In real-world applications, data structures are often accessed by multiple goroutines concurrently. This requires synchronization mechanisms that add overhead. Here’s how different approaches perform under concurrent load.

Concurrent Benchmark Results

Concurrent Access Analysis

sync.Map (Read-Heavy Workloads)

• Optimized for read-heavy scenarios with multiple readers and few writers
• Read performance: ~25.7 ns/op (constant across all sizes)
• Write performance: ~120.7 ns/op (4.7x slower than reads)
• Zero allocations for reads, minimal for writes
• Best choice when reads vastly outnumber writes (90%+ reads)

Map + RWMutex

• Read performance: ~42.3 ns/op (1.6x slower than sync.Map)
• Write performance: ~85.6 ns/op (1.4x faster than sync.Map)
• More predictable performance characteristics
• Better for balanced read/write workloads
• Simpler implementation and debugging

Slice + Mutex (Concurrent)

• Performance degrades linearly with size (same as non-concurrent)
• For 1M elements: ~12,500,000 ns/op + mutex overhead
• Not recommended for concurrent lookups at any scale
• Only viable for very small datasets (< 10 elements) with minimal contention

Concurrent Use Cases

Use sync.Map when:

• Read operations dominate (90%+ reads)
• Keys are written once and read many times
• Working with unknown or dynamic key sets
• Need lock-free reads for maximum performance

Use Map + RWMutex when:

• Balanced read/write ratio (60/40 to 80/20)
• Predictable performance is more important than peak speed
• Need range iteration or len() operations
• Want simpler code and easier debugging

Use Slice (with any locking) when:

• Dataset is extremely small (< 5 elements)
• Order preservation is critical
• Writes are rare and reads are infrequent

Benchmark Code

Sequential Access

package main

import (
    "slices"
    "testing"
)

var searchTerm = "item-5000"

func generateSlice(size int) []string {
    slice := make([]string, size)
    for i := 0; i < size; i++ {
        slice[i] = "item-" + string(rune(i))
    }
    return slice
}

func generateMap(size int) map[string]bool {
    m := make(map[string]bool, size)
    for i := 0; i < size; i++ {
        m["item-"+string(rune(i))] = true
    }
    return m
}

func BenchmarkSliceContains10(b *testing.B) {
    data := generateSlice(10)
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        _ = slices.Contains(data, searchTerm)
    }
}

func BenchmarkMap10(b *testing.B) {
    data := generateMap(10)
    b.ResetTimer()
    for i := 0; i < b.N; i++ {
        _ = data[searchTerm]
    }
}

// Similar benchmarks for 100, 1K, 10K, 100K, 500K, 1M, 10M...

Concurrent Access

package main

import (
    "sync"
    "testing"
)

// Map with RWMutex
type SafeMap struct {
    mu sync.RWMutex
    m  map[string]bool
}

func (sm *SafeMap) Load(key string) bool {
    sm.mu.RLock()
    defer sm.mu.RUnlock()
    return sm.m[key]
}

func (sm *SafeMap) Store(key string, value bool) {
    sm.mu.Lock()
    defer sm.mu.Unlock()
    sm.m[key] = value
}

func BenchmarkSafeMapRead1K(b *testing.B) {
    sm := &SafeMap{m: generateMap(1000)}
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            _ = sm.Load(searchTerm)
        }
    })
}

func BenchmarkSyncMapRead1K(b *testing.B) {
    var sm sync.Map
    for i := 0; i < 1000; i++ {
        sm.Store("item-"+string(rune(i)), true)
    }
    b.RunParallel(func(pb *testing.PB) {
        for pb.Next() {
            _, _ = sm.Load(searchTerm)
        }
    })
}

func BenchmarkSafeMapWrite1K(b *testing.B) {
    sm := &SafeMap{m: make(map[string]bool)}
    b.RunParallel(func(pb *testing.PB) {
        i := 0
        for pb.Next() {
            sm.Store("key-"+string(rune(i)), true)
            i++
        }
    })
}

func BenchmarkSyncMapWrite1K(b *testing.B) {
    var sm sync.Map
    b.RunParallel(func(pb *testing.PB) {
        i := 0
        for pb.Next() {
            sm.Store("key-"+string(rune(i)), true)
            i++
        }
    })
}

Conclusion

Maps consistently outperform slices for lookup operations across all dataset sizes. Key takeaways:

Sequential Access:

• Maps maintain O(1) lookup time (~16 ns/op) regardless of size
• slices.Contains degrades linearly: 4.53ms for 1M, 45.3ms for 10M elements
• Use maps for any dataset larger than 10 elements

Concurrent Access:

• sync.Map is fastest for read-heavy workloads (90%+ reads): ~25.7 ns/op
• Map + RWMutex offers better write performance and predictability: ~42.3 ns/op reads, ~85.6 ns/op writes
• Choose based on your read/write ratio and need for range iteration

Bottom Line: Unless you have an extremely small dataset (< 5 elements) or require strict ordering, maps are the superior choice for lookups in Go.