4 ms·

That is not a very good idea, a gc could easily take more time than your vsync, even if you didn't leak anything. It's smarter to profile your game and make sur

by tinco 14y ago

That is not a very good idea, a gc could easily take more time than your vsync, even if you didn't leak anything. It's smarter to profile your game and make sure it doesn't leak any memory, and perhaps use this feature to disable the GC altogether until play is interrupted.

kevingadd 14y ago
How exactly do you propose 'not leaking memory' in runtime environments where everything creates garbage? In .NET you at least have structs, but other environments (like JS as I gave as an example) make it impossible or near-impossible to be garbage-free. Controlling the timing of your GCs is a win there, even if a long GC can make you miss a frame. Half a GC happening during vsync instead of none of it is still a win because the hitch will be smaller.
- tinco 14y ago
  Wether the language has structs or not has nothing to do with leaking garbage. I think it's even possible to not leak memory in js, though I haven't tried that. It is absolutely not true that everything in .net creates garbage. If you leak memory in your render/update loops then that's a problem. You prevent it by never calling new and never using syntax that implicitly allocates (like foreach). Anyways, the half GCs still happen even if you enable the no gc mode. Going for the small hitch instead of for no hitch at all seems to be setting the bar too low for me. (no matter how small the hitch, if it consistently happens players will notice it and your game experience will be seriously degraded) edit: just checked out your profile, you obviously know more of what creates garbage in js than I do, so I'll believe you if you say everything creates garbage :)
  - mbq 14y ago
    You may end up writing C...
    - tinco 14y ago
      If you regard watching your memory allocations as a C thing, then perhaps. When you build real time video games this is just how it goes, whatever language you work in. You need to make sure everything is allocated _before_ you enter the game loop, wether it's C or C#. Even when you feel bothering with those details is like programming C, you still have classes, namespaces, a sane compiling and linking system and a terrific standard library. Which in my opinion makes it infinitely more comfortable than coding in C.
      - mbq 14y ago
        Note that the usually the OOP system heavily promotes short-lived memory allocations and the standard library is build around it.
  - kevingadd 14y ago
    Foreach in C# doesn't always create garbage, FYI. Enumerators can be structs - List<T>'s is, for example. It's certainly possible to write an application that doesn't structurally create garbage, but doing so isn't a universal win. Garbage-free coding patterns are more verbose, harder to get right, and often slower than relying on the GC. The reason a small hitch is better than no hitch is that if your game is running faster than your target framerate, hitches can be small enough to actually hide between frames - and control over when the GC occurs can allow you to reliably hide your GCs there.
    - profquail 14y ago
      Structs can implement IEnumerator<T> as you mentioned, but they need to be boxed before any interface methods they implement can be called. So, foreach in C# does always create at least a tiny bit of garbage -- but in the case above it's likely to be reclaimed very quickly.
      - noblethrasher 14y ago
        Normally value types do need to be boxed before calling interface methods, but C#'s `foreach` statement is special in that the collection expression just needs to conform to the "collection pattern" rather than implement a particular interface (i.e. IEnumerable). An expression conforms to the collection pattern if it has a public `GetEnumerator` method that returns a type that has a public method of type `MoveNext -> bool` and a public method of type `Current -> Type_Of_The_Element`. In other words, `foreach` uses structural typing rather than nominal typing. Incidentally, value types need only generate garbage in a `foreach` statement if they create a disposable `Enumerator`.
        profquail 14y ago
        Interesting -- I'd read about this once before but forgotten all about it. Good catch!

by tinco 14y ago

kevingadd 14y ago

How exactly do you propose 'not leaking memory' in runtime environments where everything creates garbage? In .NET you at least have structs, but other environments (like JS as I gave as an example) make it impossible or near-impossible to be garbage-free. Controlling the timing of your GCs is a win there, even if a long GC can make you miss a frame. Half a GC happening during vsync instead of none of it is still a win because the hitch will be smaller.

tinco 14y ago
Wether the language has structs or not has nothing to do with leaking garbage. I think it's even possible to not leak memory in js, though I haven't tried that. It is absolutely not true that everything in .net creates garbage. If you leak memory in your render/update loops then that's a problem. You prevent it by never calling new and never using syntax that implicitly allocates (like foreach). Anyways, the half GCs still happen even if you enable the no gc mode. Going for the small hitch instead of for no hitch at all seems to be setting the bar too low for me. (no matter how small the hitch, if it consistently happens players will notice it and your game experience will be seriously degraded) edit: just checked out your profile, you obviously know more of what creates garbage in js than I do, so I'll believe you if you say everything creates garbage :)
- mbq 14y ago
  You may end up writing C...
  - tinco 14y ago
    If you regard watching your memory allocations as a C thing, then perhaps. When you build real time video games this is just how it goes, whatever language you work in. You need to make sure everything is allocated _before_ you enter the game loop, wether it's C or C#. Even when you feel bothering with those details is like programming C, you still have classes, namespaces, a sane compiling and linking system and a terrific standard library. Which in my opinion makes it infinitely more comfortable than coding in C.
    - mbq 14y ago
      Note that the usually the OOP system heavily promotes short-lived memory allocations and the standard library is build around it.
- kevingadd 14y ago
  Foreach in C# doesn't always create garbage, FYI. Enumerators can be structs - List<T>'s is, for example. It's certainly possible to write an application that doesn't structurally create garbage, but doing so isn't a universal win. Garbage-free coding patterns are more verbose, harder to get right, and often slower than relying on the GC. The reason a small hitch is better than no hitch is that if your game is running faster than your target framerate, hitches can be small enough to actually hide between frames - and control over when the GC occurs can allow you to reliably hide your GCs there.
  - profquail 14y ago
    Structs can implement IEnumerator<T> as you mentioned, but they need to be boxed before any interface methods they implement can be called. So, foreach in C# does always create at least a tiny bit of garbage -- but in the case above it's likely to be reclaimed very quickly.
    - noblethrasher 14y ago
      Normally value types do need to be boxed before calling interface methods, but C#'s `foreach` statement is special in that the collection expression just needs to conform to the "collection pattern" rather than implement a particular interface (i.e. IEnumerable). An expression conforms to the collection pattern if it has a public `GetEnumerator` method that returns a type that has a public method of type `MoveNext -> bool` and a public method of type `Current -> Type_Of_The_Element`. In other words, `foreach` uses structural typing rather than nominal typing. Incidentally, value types need only generate garbage in a `foreach` statement if they create a disposable `Enumerator`.
      - profquail 14y ago
        Interesting -- I'd read about this once before but forgotten all about it. Good catch!