Pada beberapa 2017, selama debugging di VS, kinerja dalam proyek turun ~ 80%, mengubah game menjadi koleksi berbagai frame asinkron. Pelakunya adalah fungsi SetThreadName di dalam kolam.Siapa yang tidak terbiasa - ThreadPool adalah sejenis manajer yang bertanggung jawab untuk eksekusi paralel dari kode yang sama. Sebagai contoh, dimungkinkan untuk mendistribusikan siklus. Esensinya adalah membuat beberapa utas (1 pekerja untuk setiap inti) dan mentransfer untuk menunggu / menghapus setelah menyelesaikan pekerjaan.SetThreadName tampak seperti ini: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)
}
Di WinSDK baru, peretasan lama yang bagus dengan RaiseException dapat diganti dengan SetThreadDescription , yang pada akhirnya menyelamatkan situasinya. Karena RaiseException adalah operasi yang agak lambat.Ada beberapa pintu keluar yang optimal dari situasi ini:- Jangan memberi nama pekerja pada prinsipnya.
- Memberi hanya di Internet dan terus mengalir dalam mode tunggu. Metode ini buruk ketika bergabung dengan proses yang sedang berjalan - kami tidak akan lagi mengenali namanya.
- Pekerja tidak dihancurkan. Setiap tugas diperiksa keberadaan debugger yang terhubung, jika sebelumnya dinonaktifkan. IsDebugger Hadir