As you can see there is a huge space where the script just does nothing. Is there a reason for that and any way we can fix it?
This huge space only appears in some ticks. We have already tried to disable everything that our resource runs but this didn’t help much. The hangs were fewer but they were still there.
Also after a game restart the hangs became less however started to become more again over time.
Also the C# cleanup takes marginally longer in the ticks where the game hangs (normally 8µs, in that case 470µs).
It seems that maybe this is a C# problem?
… so that’s almost a millisecond, which isn’t much on the ~10ms time scale you’d have when trying to hit 100 FPS. Are you sure there’s not other things going on as well at this point that slow down the entire system momentarily? The state transition time at the start of a tick should always be constant so this is likely some external factor influencing stuff.
Running and uploading a .etl trace (using UIforETW) may help find out as those are system-wide captures.
It’s highly unlikely that the whole system lags because we have that problem on multiple systems, with different hardware configurations.
Also we have narrowed the issue down to be with how FiveM handles C# scripts, because when we install a C# resource without anything in it the issue with the lag still persists, which means its not a problem with the script itself.
We have also noticed that this issue only affects the canary build of the FiveM client, so it might be that the canary version has changed something with how C# scripts are handled.
Irrelevant. I’m again asking for information so it can be fixed. This doesn’t repro here, so this is only able to be solved with a trace file or access to a setup experiencing this issue, and a trace file is infinitely more likely to be obtained.
Also, s/system/game instance/, whatever. I’m not blaming the system itself or ‘hardware configurations’, and again it’d be easy to conclusively state what’s going on with a trace file recorded during this issue, as all you’ve provided so far is a cut-out screenshot of a profiler recording, and no conclusive repro steps.
Cool. That’s why I’m asking for a .etl so that I can actually fix it if it did turn out to be a runtime issue, but also if it were a script issue since script issues should also not lead to this.
It hasn’t - there’s no changes to the C# script runtime since at least two production releases. That’s, again, why I’m asking for a .etl file.
Ah, it seems to be slow during frames where it’s walking the GC heap to get the memory usage metric for resmon… so this shouldn’t be that slow with resmon/profiler not running.
Odd, however, how this sometimes makes a simple GC run take 25ms - are there that many random allocations?
I’ve got some tweaks lined up to Mono GC behavior, maybe some will help with this.
