[Bug 48668] rFactor2 - Physics thread slower on multiplayer mode

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=48668

--- Comment #9 from Paul Gofman <pgofman at codeweavers.com> ---
(In reply to Bernat Arlandis from comment #8)
> This patch fixes the issue completely. Now the game runs perfectly smooth in
> online sessions. Big thank you!!!
> 
> Here's a Proton build 5.0-7 with both patches applied:
> http://www.mediafire.com/file/zz1p2kabyt5ffmy/proton_5.0-local.7z/file
> 
> These are the patches for reference:
> https://github.com/ValveSoftware/Proton/issues/1420#issuecomment-639084670
> https://bugs.winehq.org/show_bug.cgi?id=48668#c7
> 
> I've applied both patches but it's the second one that fixes the multiplayer
> issue in rFactor2.

Thanks for testing this. Also, the insights provided about the physics the
thread and the way to see its load were helpful and made locating the issue
much easier than it could be.

Regarding the problem itself, there slow down comes from getsockname() function
which is called very frequently by the application, roughly ~800 times per
second from different threads. The implementation of that in Wine is rather
heavy as it involves querying the network interfaces, so the function can take
about solid 2-3ms. Applications usually do not call getsockname() often, so
that was never a problem before. The fix to this looks a bit hacky and not
fully correct. I am not immediately sure that a small but non-hacky fix is
possible, or some much longer solution to optimize getsockname() will be
considered particularly useful for upstream Wine.

In the view of that, since there is a contact with the game developer who was
so kind to look at the problem from the game's statistics side and to provide
us with the helpful information, is it maybe possible to ask him if so frequent
use of getsockname() is intentional? I can guess it might needed to track IP
address change, but in any case are there any reasons to do it that often? If
not, maybe they would want to change it and do it much less frequently? It most
likely does not impose a performance problem on Windows, but yet if it is not
really needed probably no reason to keep that in time critical threads.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.