Do you use D's GC?

[Ali Çehreli]

On 8/3/21 9:31 AM, H. S. Teoh wrote:

 > (1) Use it by default until it starts showing up as a bottleneck in your
 > profiler.
 >
 > (2) When it does show up as a bottleneck, [...]

That's engineering! :)

However, dmd's -profile=gc switch seems to have a bug reported by 
multiple people where one may get a segmentation fault (or was it 
-profile?). Even though I've seen it as well, it is not clear whether 
it's my own code causing errors in a destructor.

 > Overall, I think I got about 50-60% performance improvement just by
 > several small code changes to an essentially GC-centric codebase.

Same here.

One surprising pessimization which I have not mentioned publicly before 
was with assigning to the .length property of a buffer. Was it supposed 
to allocate? I had the following function:

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
   buffer.length = length;
}

My idea was I would blindly assign and even if the length was reduced, 
the *capacity* would not change and memory would *not* be allocated by a 
later assignment.

Unfortunately, that function was causing GC allocations at least with 
2.084.1 perhaps in the presence of other slices to the same elements in 
my program. Changing it to the following more sensible approach reduced 
the allocations a lot:

void ensureHasRoom(ref ubyte[] buffer, size_t length) {
   if (buffer.length < length) {
     buffer.length = length;
   }
}

I can't be sure now whether it was related to the presence of other 
slices. Possible... Anyway, that quick fix was a huge improvement.

Ali