En 2017, lors du débogage dans VS, les performances du projet ont chuté de ~ 80%, transformant le jeu en une collection de différents cadres asynchrones. Le coupable de la célébration était la fonction SetThreadName à l'intérieur de la piscine.Qui n'est pas familier - ThreadPool est une sorte de gestionnaire responsable de l'exécution parallèle du même code. Par exemple, il est possible de répartir les cycles. Son essence est de créer plusieurs threads (1 travailleur pour chaque cœur) et de transférer pour attendre / supprimer à la fin du travail.SetThreadName ressemblait à ceci: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)
}
Dans le nouveau WinSDK, le bon vieux hack avec RaiseException peut être remplacé par SetThreadDescription , ce qui sauve finalement la situation. Parce que RaiseException est une opération assez lente.Il y avait plusieurs sorties optimales de la situation:- Ne donnez pas de nom aux travailleurs en principe.
- Donner uniquement sur Internet et garder les flux en attente. Cette méthode est mauvaise lorsque vous rejoignez un processus en cours d'exécution - nous ne reconnaîtrons plus les noms.
- Les travailleurs ne sont pas détruits. Chaque tâche est vérifiée pour la présence d'un débogueur connecté, s'il était précédemment désactivé. IsDebuggerPresent