Description
As the project grows (currently 16 games + menu system), audit the binary size, startup time, and runtime performance to establish baselines and identify optimization opportunities.
Audit Areas
Binary Size
- Current size of `cli-play` binary
- Size contribution per game package (`go build` with/without specific packages)
- Dependency tree size (lipgloss, bubbletea, etc.)
- Stripping debug info: `-ldflags="-s -w"`
- UPX compression feasibility
Startup Time
- Cold start to menu render (profile with `time`)
- Game initialization cost (per-game `New()` timing)
- Are we initializing things we don't need upfront?
Runtime Performance
- Frame render time in menu (with animations, blink, tip ticker)
- Game render time (especially Snake/Tetris with tick-based updates)
- Memory allocation patterns (`go tool pprof`)
Optimization Strategies to Consider
- Lazy game package loading (only import when selected)
- Build tags for game subsets (`go build -tags "core"` for just the top 6)
- Shared style instances (currently each game creates its own lipgloss styles)
- Pre-rendered static strings for unchanging UI elements
Deliverable
- Baseline measurements (binary size, startup time, memory)
- Top 5 optimization opportunities ranked by impact/effort
- Recommended size/performance budget for adding new games
When
Not urgent -- do this before adding more than ~25 games total, or when users report sluggishness.
Description
As the project grows (currently 16 games + menu system), audit the binary size, startup time, and runtime performance to establish baselines and identify optimization opportunities.
Audit Areas
Binary Size
Startup Time
Runtime Performance
Optimization Strategies to Consider
Deliverable
When
Not urgent -- do this before adding more than ~25 games total, or when users report sluggishness.