Making Games Start Fast: A Story About Concurrency
summary
Uses Intel VTune to find heavy mutex contention inside the filesystem layer (fizsfest) and shows that a single global lock causes ~50 seconds of spin-wait on a 60 s startup. Removing thread-local locking, narrowing lock scopes, and promising a read-only mount phase eliminates most waits and raising CPU utilization; switching renderer support to DX11 and parallelizing asset uploads cuts startup from ~60s to ~17–20s. Demonstrates tactical refactors that work and where full refactors would be needed.
AI-written summary · about
chapters (13)
- 0:00Introduction and speaker intro
- 1:13Talk overview and demo setup
- 3:42Live demo of game startup
- 7:17Profiling startup performance
- 13:59The problem with mutexes and locks
- 23:30Fixing filesystem library bottlenecks
- 31:21Improving localization and audio loading
- 33:49DirectX 9 limitations and console insights
- 36:40Parallelizing asset loading
- 41:14Tactical lock scope reduction
- 47:21Async loading and user workflow
- 55:05Key lessons and unexpected gains
- 1:00:30Q&A and closing remarks
related talks
57mOptimising Data Building In Game Development
26mTackling Contention: The Monsters Inside the 'sync.Locker'
01h 14mMultithreading in UI application: When some threads are more equal than others
25mTackling Contention : The Monster in sync.Locker
52mBuilding more efficient locks
01h 04mAtomics, Locks, and Tasks (part 2 of 2)
01h 38mLock-free Programming is Dead - Long Live Lock-free Programming!
01h 01mGame engine using STD C++ 11