In some 2017, during debugging in VS, the performance in the project fell by ~ 80%, turning the game into a collection of various asynchronous frames. The culprit of the celebration was the function SetThreadName inside the pool.Who is not familiar - ThreadPool is a kind of manager responsible for parallel execution of the same code. For example, it is possible to distribute cycles. Its essence is to create several threads (1 worker for each core) and transfer to wait / delete upon completion of work.SetThreadName looked like this:void SetThreadName(DWORD dwThreadID, const char* threadName) {
THREADNAME_INFO info;
info.dwType = 0x1000;
info.szName = threadName;
info.dwThreadID = dwThreadID;
info.dwFlags = 0;
#pragma warning(push)
#pragma warning(disable: 6320 6322)
__try{
RaiseException(MS_VC_EXCEPTION, 0, sizeof(info) / sizeof(ULONG_PTR), (ULONG_PTR*)&info);
}
__except (EXCEPTION_EXECUTE_HANDLER){
}
#pragma warning(pop)
}
In the new WinSDK, the good old hack with RaiseException can be replaced with SetThreadDescription , which ultimately saves the situation. Because RaiseException is a rather slow operation.There were several optimal exits from the situation:- Do not give workers names in principle.
- To give only at an Internet and to keep flows in a waiting mode. This method is bad when joining a running process - we will no longer recognize the names.
- Workers are not destroyed. Each task is checked for the presence of a connected debugger, if it was previously disabled. IsDebuggerPresent