From: Paul Gofman pgofman@codeweavers.com
--- dlls/dbghelp/module.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/dlls/dbghelp/module.c b/dlls/dbghelp/module.c index 3f009b6b1ef..d604d4f4b2c 100644 --- a/dlls/dbghelp/module.c +++ b/dlls/dbghelp/module.c @@ -1290,6 +1290,12 @@ BOOL WINAPI EnumerateLoadedModulesW64(HANDLE process, WCHAR* wowdir = NULL; size_t sysdir_len = 0, wowdir_len = 0;
+ if (process != GetCurrentProcess() && GetCurrentProcessId() == GetProcessId(process)) + { + TRACE("same process.\n"); + process = GetCurrentProcess(); + } + /* process might not be a handle to a live process */ if (!IsWow64Process2(process, &pcs_machine, &native_machine)) {
Deadlock calls dbghelp.EnumerateLoadedModulesW64() each 5 minutes while in match and that now takes 400-500ms (with the game having ~180 modules loaded), that is already with process_vm_readv optimization in place, the server calls for each ReadProcessMemory() is taking majority of time. That is called de-facto for the current process but with the handle not being current process pseudo-handle. This a bit ad-hoc but simple optimization brings the time to about 10ms.
That is still much slower than on Windows where that takes about 0.5ms. Further optimization is possible by not relying on kernelbase functions and instead traversing the process loader information in dbghelp (which would allow to traverse that just once instead of 180 times for each module). Yet ReadProcessMemory() is going to take much more time than on Windows due to extra server calls and avoiding that when possible seems beneficial regardless.
- to be noted: access rights on GetCurrentProcess() and process handle could be different. Not sure it matters much for RL apps. - likely PssCaptureSnapshot() and friends would be a better place to implement the speedups rather than tweaking dbghelp.