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