digitalmars.D - GC behavior
- Jonathan (10/10) Oct 06 2014 If I pool all unused objects such that no object needs to be
- Daniel Murphy (5/10) Oct 06 2014 A GC collection will run when you allocate with 'new' and there is not
- Kiith-Sa (14/24) Oct 06 2014 Suggestion (may or may not be useful depending on your game): use
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
"Daniel Murphy" <yebbliesnospam gmail.com> "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
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
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
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.dYeah, 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