Während des Debuggens in VS im Jahr 2017 sank die Leistung des Projekts um ~ 80%, wodurch das Spiel in eine Sammlung verschiedener asynchroner Frames umgewandelt wurde. Schuld an der Feier war die Funktion SetThreadName im Pool.Wer ist nicht vertraut - ThreadPool ist eine Art Manager, der für die parallele Ausführung desselben Codes verantwortlich ist. Beispielsweise ist es möglich, Zyklen zu verteilen. Im Wesentlichen müssen mehrere Threads erstellt werden (1 Worker für jeden Kern) und nach Abschluss der Arbeit zum Warten / Löschen übertragen werden.SetThreadName sah folgendermaßen aus: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)
}
Im neuen WinSDK kann der gute alte Hack mit RaiseException durch SetThreadDescription ersetzt werden , was letztendlich die Situation rettet. weil RaiseException ist eine ziemlich langsame Operation.Es gab mehrere optimale Ausgänge aus der Situation:- Geben Sie den Arbeitern grundsätzlich keine Namen.
- Nur im Internet geben und Flows im Wartemodus halten. Diese Methode ist schlecht, wenn Sie einem laufenden Prozess beitreten. Die Namen werden nicht mehr erkannt.
- Arbeiter werden nicht zerstört. Jede Aufgabe wird auf das Vorhandensein eines verbundenen Debuggers überprüft, sofern dieser zuvor deaktiviert wurde. IsDebuggerPresent