Open I-ToRTUGa-I opened 6 hours ago
For reference, the cause was found in #6491:
On my machine in a debug build, the constructor to
ProcessWindows
takes about 380ms for Grounded. It's largely fromHostWindows::modules()
and I think that is mostly time spent inVirtualQueryEx
.To be fair,
VirtualQueryEx()
is called several times (at least once per module) but it has no business taking so long just to retrieve some info.And I'm not aware of another way to read the info we need...
I'm not aware how this plugin needs the information from
VirtualQueryEx()
anyway. It just needs the base address of the executable module. I think that tends to be the first module, but even if it looks modules up by name, the name is part of theMODULEENTRY32
from iterating withModule32First
andModule32Next
. So, at least for this plugin, it seems likeHostWindows::modules()
is doing a lot more work than it needs.Nevertheless, it's probably not a bad idea to run this plugin initialization stuff in another thread instead of the main/GUI thread. But I haven't looked into how much work that would be.
You're absolutely right. We simply never noticed the issue until the new plugin framework became a thing (
HostWindows
already existed prior to that).In my opinion plugin initialization should happen in a separate thread in any case, especially because the plugins that may be installed by a user are not guaranteed to be programmed correctly.
As for the modules: only a few games I've encountered hold memory areas of interest in libraries rather than the (main) executable. Refactoring the interface so that it doesn't iterate through all modules by default would make fully sense.
Upon further investigation, VirtualQueryEx()
appears to acquire some kind of lock in the target process, which explains the poor performance. The locking mechanism is probably there to prevent potential race conditions, but in my opinion it's just a bad design overall.
In any case, we'll take care of improving our own code so that the client is not affected by that anymore.
I hope you can solve this problem. This app has huge potential. I wish I was a coder to understand all this and help you... Thank you for answering.
No worries, this is high priority for us.
Description
So I was trying to use positional audio in Left 4 Dead 2 (2.2.4.1). "Link to game and transmit position", "enable" and "PA" for Source Engine is ticked, but Mumble is getting super laggy and freezing every 2 seconds for me and my friend when the game is launched. Like voice is cracking and even the windows of the program freeze when you move them. Despite this, we checked if the positional audio even works and no, it's not working. We hear each other like in a normal chat (with voice cracking and huge latency ofc huh)
P.S. I am using Mumble for the first time, and there are no specific guides for L4D2.
Steps to reproduce
Mumble version
1.5.634
Mumble component
Client
OS
Windows
Reproducible?
Yes
Additional information
No response
Relevant log output
No response
Screenshots
No response