Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Explore running RakLib without a thread #6294

Open
dktapps opened this issue Mar 20, 2024 · 0 comments
Open

Explore running RakLib without a thread #6294

dktapps opened this issue Mar 20, 2024 · 0 comments
Labels
Category: Network Related to the internal network architecture Performance

Comments

@dktapps
Copy link
Member

dktapps commented Mar 20, 2024

Description

For years, RakLib has been running within a thread.
However, this creates various issues, reduces flexibility, and the performance gains might not actually be worth it.

RakLib itself is a black box. No one knows how well it performs, but since it's doing relatively little work, it might actually improve performance to take the threads out of the picture.

Moving RakLib onto the main thread would allow for tighter integration between PM and RakLib, making it easier to, for example, directly collect session statistics.

Alternative methods

@dktapps dktapps added Category: Network Related to the internal network architecture Performance labels Mar 20, 2024
dktapps added a commit that referenced this issue Apr 23, 2024
as discussed in #6294, investigation is needed into whether the high complexity of threading is actually even worth the performance gains.
we don't even know for sure that running RakLib on a thread actually improves performance.

this implementation is sub-optimal right now, since it ticks too slowly (20 Hz vs RakLib's 100 Hz), and tickProcessor() also sleeps (which I can't disable with this version of RakLib).
however, it's useful as a foundation to see how this will behave if we were to get rid of the RakLib thread.
dktapps added a commit that referenced this issue Apr 23, 2024
as discussed in #6294, investigation is needed into whether the high complexity of threading is actually even worth the performance gains.
we don't even know for sure that running RakLib on a thread actually improves performance.

this implementation is sub-optimal right now, since it ticks too slowly (20 Hz vs RakLib's 100 Hz), and tickProcessor() also sleeps (which I can't disable with this version of RakLib).
however, it's useful as a foundation to see how this will behave if we were to get rid of the RakLib thread.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Category: Network Related to the internal network architecture Performance
Projects
None yet
Development

No branches or pull requests

1 participant