5 ms·

I just want to say that no, you don’t need to free the resources. It's very possible to use a fix amount of heap memory during the whole lifecycle of your game.

I just want to say that no, you don’t need to free the resources. It's very possible to use a fix amount of heap memory during the whole lifecycle of your game. In fact I think that’s what people should aim for in 90% of the cases.

axaxs 7y ago
You can do the same thing in GC'd languages, though.
- billjings 7y ago
  Here's the easy question: can you do manual GC in a GC'd environment? Yes, of course you can. Here's the harder question: how hard is it to do manual GC in a GC'd environment vs. a non-GC'd environment? "Environment" is the key word here. Because if you're writing in a GC'd environment, there's a good chance that existing code - third party, first party, wherever it comes from - assumes that it can heap allocate objects and discard them without too much thought. So for small scale optimizations where you own it all, it can work out fine. But if that optimization needs to bust through an abstraction layer, all of a sudden the accounting structure of the whole program has changed, and the optimization has turned into a major surgical operation.
  - kenoath 7y ago
    This was almost exactly my experience when I wrote a network simulator in Go and tried to improve the performance. The gc pauses reached tens of seconds haha, I made a lot of garbage. I'm not completely sure if this is true but I think that doing things in an "OO" style where for example, every different event was it's own type which satisfies the Event interface basically means that different events can't occupy an array together and that I think that each one may hold a pointer to some heap allocated memory, so you really can't optimise this away without ripping up the entire program. Rather than do so, I ended up running my Sim on a server with >100 cores, it was single threaded but they would all spin up and chomp the GC, a beautiful sight. Another factor is just the general lack of transparency or knowability of where and how objects occupy memory in these languages. If memory management is likely to be a concern it is absolutely much easier in an environment where it is prioritized than one where it is ignored.
- boomlinde 7y ago
  In which the garbage collector serves no advantage; only as a trap you have to remind yourself to step over.
  - jayd16 7y ago
    It serves the huge purpose of doing 100% of the tracking work. Whats easier? Manually tracking all of your allocations and frees as well as worrying about double frees and pointer ownership or calling GC.Collect() during a load screen?
    - boomlinde 7y ago
      What's easier? Knowing that you can use all your memory again after you've explicitly freed the resources you used, or knowing that you can use all your memory again after a call to GC.Collect() does god-knows-what?
      - jayd16 7y ago
        I think the garbage collector is easier over all, obviously.

axaxs 7y ago

You can do the same thing in GC'd languages, though.

billjings 7y ago
Here's the easy question: can you do manual GC in a GC'd environment? Yes, of course you can. Here's the harder question: how hard is it to do manual GC in a GC'd environment vs. a non-GC'd environment? "Environment" is the key word here. Because if you're writing in a GC'd environment, there's a good chance that existing code - third party, first party, wherever it comes from - assumes that it can heap allocate objects and discard them without too much thought. So for small scale optimizations where you own it all, it can work out fine. But if that optimization needs to bust through an abstraction layer, all of a sudden the accounting structure of the whole program has changed, and the optimization has turned into a major surgical operation.
- kenoath 7y ago
  This was almost exactly my experience when I wrote a network simulator in Go and tried to improve the performance. The gc pauses reached tens of seconds haha, I made a lot of garbage. I'm not completely sure if this is true but I think that doing things in an "OO" style where for example, every different event was it's own type which satisfies the Event interface basically means that different events can't occupy an array together and that I think that each one may hold a pointer to some heap allocated memory, so you really can't optimise this away without ripping up the entire program. Rather than do so, I ended up running my Sim on a server with >100 cores, it was single threaded but they would all spin up and chomp the GC, a beautiful sight. Another factor is just the general lack of transparency or knowability of where and how objects occupy memory in these languages. If memory management is likely to be a concern it is absolutely much easier in an environment where it is prioritized than one where it is ignored.
boomlinde 7y ago
In which the garbage collector serves no advantage; only as a trap you have to remind yourself to step over.
- jayd16 7y ago
  It serves the huge purpose of doing 100% of the tracking work. Whats easier? Manually tracking all of your allocations and frees as well as worrying about double frees and pointer ownership or calling GC.Collect() during a load screen?
  - boomlinde 7y ago
    What's easier? Knowing that you can use all your memory again after you've explicitly freed the resources you used, or knowing that you can use all your memory again after a call to GC.Collect() does god-knows-what?
    - jayd16 7y ago
      I think the garbage collector is easier over all, obviously.