Minimize GC memory footprint

[Bastiaan Veelo]

On Wednesday, 3 February 2021 at 13:37:42 UTC, frame wrote:
> 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

?? Do you mean no collections happen? 32bit GC should just work.

> 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

That looks like a bug indeed.

> 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.

I think it means that you need to make sure that enable() is 
called as many times as disable() is called before collection can 
happen automatically.

— Bastiaan.