In profiles of RMC-14, encrypting network messages accounted for ~8% of main thread time. That's a lot.
Each NetChannel has an "encryption channel" which gets processed on the thread pool.
It is our suggestion for a long while to keep the TPS at 30 for servers. However the default was always 60.
I believe its better to have it as a default.
* Clamp audio tickrate
I am reasonably sure I saw a recommended 30TPS figure somewhere but I cannot find it again. At any rate I can't notice this but imagine it provides significant benefits for people on 144hz+ monitors.
* rn
---------
Co-authored-by: Pieter-Jan Briers <pieterjan.briers+git@gmail.com>
* Add VisibilityChanged virtual to Control
* Defer updating invisible OutputPanels on UIScale change
DebugConsole falls under this when not hidden, and it significantly improves perf of e.g. resizing the window when there's a lot of stuff in there.
* Avoid redundant UI Scale updates on window resize.
Window resizing can change the UI scale, due to the auto-scaling system. This system had multiple perf issues:
UI scale was set and propagated even if it didn't change (system disabled, not effective, etc). This was just wasted processing.
UI scale was updated for every window resize event. When the game is lagging (due to the aforementioned UI scale updates being expensive...) this means multiple window resize events in a single frame ALL cause a UI scale update, which is useless.
UI scale updates from resizing now avoid doing *nothing* and are deferred until later in the frame for natural batching.
* Reduce allocations/memory usage of various rich-text related things
Just allocate a buncha dictionaries what could possibly go wrong.
I kept to non-breaking-changes which means this couldn't as effective as it should be.
There's some truly repulsive stuff here. Ugh.
* Cap debug console content size.
It's a CVar.
OutputPanel has been switched to use a new RingBufferList datastructure to make removal of the oldest entry efficient.
---------
Co-authored-by: metalgearsloth <31366439+metalgearsloth@users.noreply.github.com>
* Perf: Improve replay playback responsiveness
- new CVAR ReplayMaxScrubTime
- There is a time budget when applying replay ticks updates of only 10 ms
- Ensure we don't apply checkpoints that move us backwards in time by accident
- Prevent double-lookup of checkpoints.
* Fix merge error
* Fix it again, but for real this time
---------
Co-authored-by: ElectroJr <leonsfriedrich@gmail.com>
* perf: Replays use less memory for checkpoints (#28052)
- Simple change of the CVars and some stats
- Based on a Lizard replay, checkpoints move from on average every 70 ticks to every 350.
* Set a minimum number of ticks that must pass between checkpoints
* Fix stat collection, split _checkpointMinInterval, more CheckpointState
* update release notes
Reports of problems, double checked with Grafana. Great.
I am going to do manual test runs of this system against Miros again if I end up looking to improve the situation.
Some players continue to have "stuck at connected" issues connecting to
most servers, but apparently this issue has become more prominent in the
last two weeks or so?
It is almost certainly an MTU problem because there are at least two
servers on the hub that run a lower default MTU, and these players had
no problem connecting to them. For one of these reporters, I actually
increased the MTU to 1000 and they could no longer connect, and could
connect again once it was lowered to 900.
It's not clear what recent changes, either to the codebase or to the
public Internet that have been exercising this MTU issue more. For those
experiencing MTU issues, it seems that connecting to a less full server
results in higher probability of success.
Nevertheless, bringing down the default MTU and then possibly enabling
MTU expansion in the future would make this game playable for a small
but not insignificant bit of players.
This callback enables code to update its metrics only when required. Needed this for SS14 since online admin count stats are not something I want to update on an "arbitrary" basis.
Tons of consideration and commenting for how this plays in with stuff like dotnet-counters. Added the metrics.update_interval CVar to act as a fallback for this event when dotnet-counters and such is in use.
They tend to get cut off (or well did on wizden before pjb changed it to this exact value bigger along with another patch). Before you got around 2ish hours in a replay before it stopped. I doupt most servers will reach 6ish hours before this takes effect. But those servers can increase this value of needed.
* Reapply "Fix replay int overflow issues." (#4802)
This reverts commit 32049e34f2.
* IConfigurationManager.LoadDefaultsFromTomlStream now does required type conversions.
This fixes scenarios like loading of `long` CVars.
It makes no sense for our use case, and it caused FluidSynth to allocate a different thread pool *per* mixer. And every one of those threads have *high* priority. That's like *really* bad.
Furthermore, it was based on ParallelProcessCount which is currently bugged, and because of that we were always allocating 256 (!!!) real OS threads for a MIDI synthesizer. CHRIST. (fix for ParallelProcessCount is separate)
I assume this is responsible for a ton of people's MIDI lag, it just murdering their PC's CPU scheduler.
The ability to multithread FluidSynth still exists as a CVar but it'll default to 1 and I don't think it makes sense to ever change it.
Also there was code to dynamically change the parameter, as far as I could test this just always crashed the process so out it goes.
