Hi,

Using Visual Studio 2015 and the concurrency visualizer plugin (which is a nice tool btw) I found that while my app has bad perf (ie 10 fps), all threads (they are 4 of them) are mostly idling.

The rendering thread is spending 24 ms emitting draw command (with dx12), then for 80 ms it mostly sleeps, periodically waking up (likely to know if synchronisation did occur). The GPU workload is small even if it takes 24 ms to submit a command list and complete almost immediatly.

The 3 others threads are idling, periodically waking up too.

Is there an easy way to determine which part of the code is making a thread idle ? Since this is a big project, and involves runtime compiled code, wrapping every std::mutex/std::sleep/std::wait_for inside a logging function is quite difficult (likely to miss a wait mechanism, ...).

Since there are tools that recognises when a thread is idling I would expect there are tools that would help to know what makes a thread idle ?

Regards, Vincent.

The blunt-force approach is to find a place where you know you are idling in some number of threads (you seem to have found a couple candidates already) and put a breakpoint in there. Set it to fire at some high hit count like 500 so you can get a few frames of stabilization before it fires. When it goes off, open the VS Threads window and look at the associated callstacks.

I'm sure there are more sophisticated approaches but that works for me 90% of the time :-)

If stalls are long enough to be a performance problem, they'll show up on a regular profiler. I wrote a really simple hierarchical, intrusive profiler for my engine, which writes timestamps to memory and then dumps JSON to disk for viewing in chrome's visualizer:

As you can see, I also mark known blocking functions in there, such as "Yield", "wait for task", etc... It's then pretty easy to look at the visual data and find out exactly why and when each thread is stalling.