6 ms·

> if you invoke GC intentionally at convenient timing boundaries (I.e., after each frame), Manually invoking GC many times per second is a viable approach?

bob1029 2y ago
It has worked well in my prototypes. There is a reason a GC.Collect method is exposed for use.
- smaudet 2y ago
  At least for this instance you have a good idea which objects are "ripe" for collection. There should be some way to specify "collect these, my infra objects don't need to be".
munificent 2y ago
It can be, yes. You're basically trading off worse throughput for better latency. If you forcibly run the GC every frame, it's going to burn cycles repeatedly analyzing the same still-alive objects over and over again. So the overall performance will suffer. But it means that you don't have a big pile of garbage accumulating across many frames that will eventually cause a large pause when the GC runs and has to visit all of it. For interactive software like games, it is often the right idea to sacrifice maximum overall efficiency for more predictable stable latency.
- neonsunset 2y ago
  This might be more problematic under CoreCLR than under Unity. Prematurely invoking GC will cause objects that are more likely to die in Gen 0 to be promoted to Gen 1, accumulate there and then die there. This will cause unnecessary inter-generational traffic and will extend object lifetimes longer than strictly necessary. Because live object count is the main factor that affects pause duration, this may be undesirable. It might be more useful to use OSU! approach as a reference: https://github.com/dotnet/runtime/issues/96213#issuecomment-2155746773 https://github.com/dotnet/runtime/issues/96213#issuecomment-... OSU! represents an extreme case where the main game loop runs at 1000hz, so for much more realistic ~120hz you have plenty of options.
  - smaudet 2y ago
    If you could even just pass an array of objects to be collected or something, this would so much easier. Magic, code or otherwise, sucks when the spell/library/runtime has different expectations than your own. You expect levitation to apply to people, but the runtime only levitates carbon based life forms. You end up levitating people without their affects (weapons/armor), to the embarrassment of everyone. There should be no magic, everything should be parameterized, the GC is a dangerous call, but it should be exposed as well (and lots of dire warnings issued to those using it).
    - munificent 2y ago
      > If you could even just pass an array of objects to be collected or something If you have a bunch of objects in an array that you have a reference to such that you can pass it, then, by definition, those objects are not garbage, since they're still accessible to the program.
      - smaudet 2y ago
        Yes. Use a WriteOnlyArray or whatever, Semantics aside though... There should be some middle ground between RAII and invoking Dispose/delete and full blown automatic GC.

bob1029 2y ago

It has worked well in my prototypes. There is a reason a GC.Collect method is exposed for use.

smaudet 2y ago
At least for this instance you have a good idea which objects are "ripe" for collection. There should be some way to specify "collect these, my infra objects don't need to be".

munificent 2y ago

It can be, yes. You're basically trading off worse throughput for better latency. If you forcibly run the GC every frame, it's going to burn cycles repeatedly analyzing the same still-alive objects over and over again. So the overall performance will suffer. But it means that you don't have a big pile of garbage accumulating across many frames that will eventually cause a large pause when the GC runs and has to visit all of it. For interactive software like games, it is often the right idea to sacrifice maximum overall efficiency for more predictable stable latency.

neonsunset 2y ago
This might be more problematic under CoreCLR than under Unity. Prematurely invoking GC will cause objects that are more likely to die in Gen 0 to be promoted to Gen 1, accumulate there and then die there. This will cause unnecessary inter-generational traffic and will extend object lifetimes longer than strictly necessary. Because live object count is the main factor that affects pause duration, this may be undesirable. It might be more useful to use OSU! approach as a reference: https://github.com/dotnet/runtime/issues/96213#issuecomment-2155746773 https://github.com/dotnet/runtime/issues/96213#issuecomment-... OSU! represents an extreme case where the main game loop runs at 1000hz, so for much more realistic ~120hz you have plenty of options.
- smaudet 2y ago
  If you could even just pass an array of objects to be collected or something, this would so much easier. Magic, code or otherwise, sucks when the spell/library/runtime has different expectations than your own. You expect levitation to apply to people, but the runtime only levitates carbon based life forms. You end up levitating people without their affects (weapons/armor), to the embarrassment of everyone. There should be no magic, everything should be parameterized, the GC is a dangerous call, but it should be exposed as well (and lots of dire warnings issued to those using it).
  - munificent 2y ago
    > If you could even just pass an array of objects to be collected or something If you have a bunch of objects in an array that you have a reference to such that you can pass it, then, by definition, those objects are not garbage, since they're still accessible to the program.
    - smaudet 2y ago
      Yes. Use a WriteOnlyArray or whatever, Semantics aside though... There should be some middle ground between RAII and invoking Dispose/delete and full blown automatic GC.