Spawning threads isn't free

2026-07-18 - 2 minutes

• Spawning threads is expensive
• Avoid contention on start and completion
• Be mindful of your workload

Lately I’ve been writing on a media gallery and it turned out to be a large lerning opportunity. In desktop applications, nothing can ever block the UI thread, or a user will notice. Loading textures, even if it’s gigabytes per second, should never wait on the UI thread for completion. Neither should unloding those.

So I’ve quickly started moving everything CPU or IO intensive onto background threads. Interesting observations I made:

🔗Spawning threads is expensive

The speed of that operation mostly depend on your programming language and OS but starting up a single thread can vary between 100-250us, which sums up to mulitple milliseconds on bigger CPUs. Meanwhile waking up an entire prepared work pool takes up less than 50us.

This is not a huge issue when each task takes a long time but if you have a lot of small work pieces, avoid spawning threads over and over.

🔗Avoid contention on start and completion

Prepare resources ahead of time. Your workpool should probably persist the scratch memory for whatever algorithm it’s using. Having all your threads start up to content for your allocator eliminates your gains quickly. Thrashing your cache to write back the results can also cost you milliseconds.

🔗Be mindful of your workload

If you know that you have a large set of CPU heavy workloads, you probably shouldn’t spawn more threads than you have physical processing cores. In my experience the gains afterwards are minimal.