En algunos 2017, durante la depuración en VS, el rendimiento en el proyecto se redujo en ~ 80%, convirtiendo el juego en una colección de varios cuadros asincrónicos. El culpable de la celebración fue la función SetThreadName dentro de la piscina.Quién no está familiarizado: ThreadPool es un tipo de administrador responsable de la ejecución paralela del mismo código. Por ejemplo, es posible distribuir ciclos. Su esencia es crear varios subprocesos (1 trabajador para cada núcleo) y transferirlos a esperar / eliminar al finalizar el trabajo.SetThreadName se veía así: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)
}
En el nuevo WinSDK, el viejo truco con RaiseException se puede reemplazar con SetThreadDescription , que finalmente salva la situación. Porque RaiseException es una operación bastante lenta.Hubo varias salidas óptimas de la situación:- No les dé nombres a los trabajadores en principio.
- Dar solo en Internet y mantener los flujos en modo de espera. Este método es malo cuando se une a un proceso en ejecución: ya no reconoceremos los nombres.
- Los trabajadores no son destruidos. Cada tarea se verifica para detectar la presencia de un depurador conectado, si anteriormente estaba deshabilitado. IsDebuggerPresent