Minimize GC memory footprint

frame frame86 at live.com
Wed Feb 3 13:37:42 UTC 2021


On Sunday, 31 January 2021 at 12:14:53 UTC, Imperatorn wrote:

> It says experimental, but it's fine:
>
> https://dlang.org/phobos/std_experimental_allocator.html

Well, this looks very nice but I have to deal with GC as long I 
want to use other libraries that are relying on it or even just 
phobos.

Conclusion so far (for Windows):

32bit:
- GC just doesn't work at all

64bit:
- Collections are rare. It can be necessary to call GC.collect() 
manually.
- Scope guards to explicit clean up / free memory at function 
exit have no deep impact on most cases.
- If your application should save memory call GC.minimize() when 
it's appropriate.


It seems that calling GC.enable() if it's already enabled just 
disables the automatic GC again? Is this a bug? I cannot 
reproduce it outside my application yet since it's not clear when 
the GC starts collecting, but it always shows the same behaviour:

> // GC.enable();
Case A: The app is very kind in memory usage (~20 MB)

> GC.enable();
Case B: The app is consuming huge amount of memory (~900 MB)

> GC.disable();
> GC.enable();
Case A again

> GC.disable();
> GC.enable();
> GC.enable();
Case B again


I also have to struggle what the specs' text actually mean:

> This function is reentrant, and must be called once for every 
> call to disable before automatic collections are enabled.



More information about the Digitalmars-d-learn mailing list