Understanding gc memory profile report

[Ali Çehreli via Digitalmars-d-learn]

Although I responded below, I'm curious on what others think about this 
question.

On 09/08/2017 02:13 AM, John Burton wrote:
 > I wrote this simple program to test out my understanding of memory
 > allocation :-

I changed it to display the location and capacity:

import std.stdio;

void info(A)(A array) {
     writefln("ptr: %s, capacity: %s, length: %s",
              array.ptr, array.capacity, array.length);
}

void main()
{
     int [] array = new int[250];

     info(array);

     // Append one value to the array
     array ~= 123;
     info(array);
}

Sample output:

ptr: 7FD9B63CD000, capacity: 255, length: 250
ptr: 7FD9B63CD000, capacity: 255, length: 251

 > I compiled it with 'dmd test.d -profile=gc'
 >
 > After running it, the profile report was :-
 >
 >     bytes allocated, allocations, type, function, file:line
 >                2000               1 int[] D main test.d:5
 >                   4               1 int[] D main test.d:10

Here's my output with v2.076.0-dirty (that really is the version :o)):

            4000	              1	int[] D main deneme.d:412
              72	              1	std.format.FormatException 
std.exception.enforceEx!(FormatException).enforceEx!bool.enforceEx 
/usr/include/dmd/phobos/std/exception.d:615
              64	              2	std.array.Appender!string.Appender.Data 
std.array.Appender!string.Appender.this 
/usr/include/dmd/phobos/std/array.d:2817
              32	              1 
std.array.Appender!(char[]).Appender.Data 
std.array.Appender!(char[]).Appender.this 
/usr/include/dmd/phobos/std/array.d:2817
               4	              1	int[] D main deneme.d:417

And why is mine 4000 bytes? I guess it's the size of the underlying buffer.

 > This is not how I expected it to be. I would have expected that the
 > runtime either did not have to allocate at all at line 10 to add a new
 > element because there was already space or it would have to allocate
 > space for the new enlarged array and copy the array to it, in which case
 > I'd expect it to allocate 2004 bytes (or more) to copy the enlarged
 > array in to.
 >
 > I would not expect that it could have allocated 4 bytes to add an item
 > separably from the original 2000. Is there some way that the runtime can
 > grown the original allocation by 4 bytes and that's what I'm seeing? If
 > so, is there a limit to how much it can do this?
 >
 > Can anyone help me understand what is going on here?

I think you're right. Perhaps more accurate information is not possible 
with the current implementation. Perhaps a higher-layer function counts 
"potential" allocations without being sure whether the space could be 
used for this slice or not. The "D Slices" article has related information:

   https://dlang.org/d-array-article.html

Ali