www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - GC behavior

reply "Jonathan" <jadit2 gmail.com> writes:
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.
Oct 06 2014
next sibling parent "Daniel Murphy" <yebbliesnospam gmail.com> writes:
"Jonathan"  wrote in message news:hsdxglmqtcnhskwzrkph forum.dlang.org...

 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()'.
Oct 06 2014
prev sibling parent reply "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Monday, 6 October 2014 at 16:23:41 UTC, Jonathan wrote:
 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- evelopment-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.
Oct 06 2014
parent reply "Jonathan" <jadit2 gmail.com> writes:
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
Oct 06 2014
parent "Kiith-Sa" <kiithsacmp gmail.com> writes:
On Monday, 6 October 2014 at 17:46:34 UTC, Jonathan wrote:
 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.
Oct 06 2014