Em 2017, durante a depuração no VS, o desempenho do projeto caiu em ~ 80%, transformando o jogo em uma coleção de vários quadros assíncronos. O culpado da celebração foi a função SetThreadName dentro da piscina.Quem não está familiarizado - o ThreadPool é um tipo de gerente responsável pela execução paralela do mesmo código. Por exemplo, é possível distribuir ciclos. Sua essência é criar vários threads (1 trabalhador para cada núcleo) e transferir para aguardar / excluir após a conclusão do trabalho.SetThreadName ficou assim: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)
}
No novo WinSDK, o bom e velho hack com RaiseException pode ser substituído por SetThreadDescription , o que acaba salvando a situação. Porque RaiseException é uma operação bastante lenta.Havia várias saídas ótimas da situação:- Não dê nomes aos trabalhadores em princípio.
- Dar apenas na Internet e manter os fluxos no modo de espera. Esse método é ruim ao ingressar em um processo em execução - não reconheceremos mais os nomes.
- Trabalhadores não são destruídos. Cada tarefa é verificada quanto à presença de um depurador conectado, se ele foi desabilitado anteriormente. IsDebuggerPresent