Our great sponsors
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
In .NET, GC is triggered when a user thread runs out of memory in an allocation budget and needs more, similar to what you described [0].
Generally speaking, indefinitely preventing GC from running is not possible (you always end up putting data on the heap) therefore an optimal strategy is similar to any other language - limiting allocations and reusing memory through object and array pooling. This will ensure that GC pauses are as infrequent and as short as possible. It's important to note that if there is sufficient allocation budget - the GC will not run.
This way, in a well written code the GC may only ever trigger every few hundred frames and only take a millisecond to run. In fact, OSU! has been able to get consistently good frame times even back on .NET Framework.
[0] https://github.com/dotnet/runtime/blob/main/docs/design/core...
[1] https://maoni0.medium.com/dynamically-adapting-to-applicatio...
[2] https://github.com/jinyus/related_post_gen#multicore-results