What this means in practice - it should be possible to go full OOP crap for game simulation using lightweight classes without any hiccups even with GC enabled, but all asset data should be handled differently and taken out of GC scannable heap to avoid long pauses.

On Sunday, 1 August 2021 at 14:43:47 UTC, evilrat wrote:

I'm kind of skeptical towards tracing GC for games. Think of thousands of objects, usually of the same type. These objects are often full of references to other objects and they often points to each other as there might be some relation.

This is a lot of memory, that is also scattered around in the memory. Scanning these will take time. For this type of objects I would go for a pool that is outside GC. Also how the reference each other could be solved by reference counting in order to minimize memory leaks. Other suggestions is that object references each other using a hash table. This rolling identifier/hash lookup is often used in operating systems (file handles for example) as pointers cannot be used in order to distinguish a resource.

Often memory management in games kind of falls outside the convenience of GC as the demand is so special, not only because of performance but also when it comes to data structures.

On Sunday, 1 August 2021 at 14:43:47 UTC, evilrat wrote:

I'm kind of skeptical towards tracing GC for games. Think of thousands of objects, usually of the same type. These objects are often full of references to other objects and they often points to each other as there might be some relation.

This is a lot of memory, that is also scattered around in the memory. Scanning these will take time. For this type of objects
I would go for a pool that is outside GC. Also how the reference each other could be solved by reference counting in order to minimize memory leaks. Other suggestions is that object references each other using a hash table. This rolling identifier/hash lookup is often used in operating systems (file handles for example) as pointers cannot be used in order to distinguish a resource.

Often memory management in games kind of falls outside the convenience of GC as the demand is so special, not only because of performance but also when it comes to data structures.

It is more than enough for Flash like games, honestly plenty of indies will never make it beyond that, so why bother for the ultimate weapon if they they on the first day on the battlefield?

Don't dismiss languages on how well they can achieve Fortnight, when not even able to beat Stardew Valley or Bastion sales.

It's interesting to hear do you use D's GC? Or do you use your own custom memory management structure?

How performant is GC?

The reason I'm asking is I'm planning to dive into 3D game dev with D as a hobby in an attempt to create a game I dreamed of since I was a kid. I'd like to know if GC is worth using at all, or should I go with 100% manual memory management.

Any opinion is appreciated. Thanks in advance.

The D language claim support NOGC Programming, but there is no ecosystem for this. It force people to use GC if they want use library.

It's interesting to hear do you use D's GC? Or do you use your own custom memory management structure?

How performant is GC?

The reason I'm asking is I'm planning to dive into 3D game dev with D as a hobby in an attempt to create a game I dreamed of since I was a kid. I'd like to know if GC is worth using at all, or should I go with 100% manual memory management.

Any opinion is appreciated. Thanks in advance.

On Sunday, 1 August 2021 at 08:54:05 UTC, Kirill wrote:

The D language claim support NOGC Programming, but there is no ecosystem for this. It force people to use GC if they want use library.

D GC is not good as any other popular language.

You will find there is a lot library author abandoned they projects in last decade, people just leave after invest a lot time and resource.