В некотором 2017 году, во время отладки в VS, производительность в проекте падала на ~80%, превращая игру в сборник различных ассинхронных кадров. Виновником торжества стала функция SetThreadName внутри пула. Кто не знаком — ThreadPool — некий manager, отвечающий за параллельное выполнение одинакового кода. К примеру, так можно распралелить циклы. Суть его в создании нескольких (по 1 воркеру на каждое ядро) и перевод в ожидание/удаление по завершению работы.
SetThreadName выглядел следующим образом:
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) }
В новом WinSDK старый добрый хак с RaiseException можно заменить на SetThreadDescription, но ситуацию с ним вышла аналогичной.
Из ситуации было несколько выходов оптимальных выходов:
1. Не давать воркерам имена в принципе.
2. Давать только при ините и сохранять потоки в режиме ожидания. Такой способ плох при присоединении к запущенному процессу — имён мы уже не узнаем.
3. Воркеры не уничтожаются. Каждую задачу проверяют наличие подключенного отладчика, если до этого он был отключен. IsDebuggerPresent
ссылка на оригинал статьи https://habr.com/ru/post/489556/
Добавить комментарий