I wrote this simple program to test out my understanding of memory allocation :-

    import std.stdio;

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

        writeln(array.length, " elements ", array);

        // Append one value to the array
        array ~= 123;
        writeln(array.length, " elements ", array);
    }

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

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?

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