GC behavior

[Jonathan via Digitalmars-d]

If I pool all unused objects such that no object needs to be
GC'ed, does it still perform scanning? What are other good ways
to avoid its overhead? As you might tell, I know rather little
how D's garbage collection works. I'm working on a game engine
and trying to be as resource efficient as possible.

FYI, I've been using Rust for the last three months and decided
to take a break from it. The documentation is far from the
quality that D has and managing explicit lifetimes becomes a
serious pain during mid project, especially in cases that you
know are already safe.

[Daniel Murphy via Digitalmars-d]

If I pool all unused objects such that no object needs to be GC'ed, does
it still perform scanning? What are other good ways to avoid its overhead?
As you might tell, I know rather little how D's garbage collection works.
I'm working on a game engine and trying to be as resource efficient as
possible.

A GC collection will run when you allocate with 'new' and there is not
enough memory already reserved by the gc. So if you don't use 'new' then it
won't run a collection, otherwise it might. You can disable all collections
by importing 'core.memory' and calling 'GC.disable()'.

[Kiith-Sa via Digitalmars-d]

Post by Jonathan via Digitalmars-d
If I pool all unused objects such that no object needs to be
GC'ed, does it still perform scanning? What are other good ways
to avoid its overhead? As you might tell, I know rather little
how D's garbage collection works. I'm working on a game engine
and trying to be as resource efficient as possible.
FYI, I've been using Rust for the last three months and decided
to take a break from it. The documentation is far from the
quality that D has and managing explicit lifetimes becomes a
serious pain during mid project, especially in cases that you
know are already safe.

Suggestion (may or may not be useful depending on your game): use
an ECS
(http://t-machine.org/index.php/2007/09/03/entity-systems-are-the-future-of-mmog-development-part-1/)
approach with big, manually allocated arrays of structs in the
implementation. I'm working on something but it's not documented
enough/API is butt-ugly/not nearly stable-enough yet:
https://github.com/kiith-sa/tharsis-core

Some people are working on other ECS's too, see code.dlang.org
(some are very efficient, some are not... don't remember which).


And (very simplistic advice, but...) if ECS doesn't fit your
needs or you do use GC to allocate a lot of stuff anyway, reuse
dead objects and control the GC by disable()ing/reenabling and
explicitly fullCollect()ing.

[Jonathan via Digitalmars-d]

Kiith-Sa, thanks for the info! I started to check out your entity
project and love how your incorporating threads and syncing
new/old state. You did state that your cleaning up things, but my
initial reaction is that entitymanager is performing too many
roles. I'd remove the heavy game state and threading into another
class to make it cleaner, imho.

https://github.com/kiith-sa/tharsis-core/blob/master/source/tharsis/entity/entitymanager.d

[Kiith-Sa via Digitalmars-d]

Post by Jonathan via Digitalmars-d
Kiith-Sa, thanks for the info! I started to check out your
entity project and love how your incorporating threads and
syncing new/old state. You did state that your cleaning up
things, but my initial reaction is that entitymanager is
performing too many roles. I'd remove the heavy game state and
threading into another class to make it cleaner, imho.
https://github.com/kiith-sa/tharsis-core/blob/master/source/tharsis/entity/entitymanager.d

Yeah, the threading is currently the most work-in-progress thing
(basically, I'm dealing with tradeoffs between trying to get the
best average performance and least latency from non-realtime OS
scheduling).

EntityManager is pretty much the kitchen-sink class where things
exist until they are refactored away (most of Tharsis code used
to be there at some point in the past). It will probably end up
just as a shell delegating to all internals regarding
entit/component management and process execution. However,
EntityManager API itself is more complicated than needed for most
users (and needs to be used together with other classes which add
to the complexity) - it, together with other 'low-level' API
classes will probably eventually be hidden behind a more
user-friendly facade (yeah, I hate design patterns, but that's
pretty much what it will be), with the ability to access
EntityManager/others for more advanced users.