Minimize GC memory footprint

rikki cattermole rikki at cattermole.co.nz
Sat Feb 6 15:45:47 UTC 2021


On 07/02/2021 4:22 AM, frame wrote:
> On Saturday, 6 February 2021 at 13:30:03 UTC, rikki cattermole wrote:
> 
>> Okay, its still seeing something is alive then.
> 
> That's why I used the scope guard. I know it shouldn't have any effect 
> but I want to give the GC an extra hint ;)

The GC shouldn't be aware of the scope guard. It expands out into a try 
finally block.

>> I've compiled and ran it under ldc. Dmd in 32bit mode is certainly 
>> doing something that the GC doesn't appreciate. I can reproduce it 
>> with -m32mscoff as well. So yeah dmd specific all right.
> 
> The sad story never ends.
> 
> But seriously are there no runtime tests before releasing the next DMD? 
> The GC is a main feature of D and such things give a bad impression.

Nah, this is old. It is also bad D code.

Allocate up front and then set.

T[] buffer;
buffer.length = 1_000_000;

foreach(i, v; source[0 .. 1_000_000]) {
	buffer[i] = someOp(v);
}

This will be significantly faster, as it won't require allocating more 
than once and will prevent heap fragmentation which 32bit is severely 
affected by (hence why precise GC is important for testing on this target).


More information about the Digitalmars-d-learn mailing list