Array fill performance differences between for, foreach, slice

Steven Schveighoffer schveiguy at
Wed Apr 1 16:33:11 UTC 2020

On 4/1/20 11:23 AM, data pulverizer wrote:
> Thanks for all the suggestions made so far. I am still interested in 
> looking at the implementation details of the slice assign `arr[] = x` 
> which I can't seem to find. Before I made my initial post, I tried doing 
> a `memcpy` and `memmove` under a `for` loop but it did not change the 
> performance or get the same kind of performance as the initial slice 
> performance so I didn't bother to mention them, I haven't tried it with 
> the suggested compiler flags though.

Using disassembly, on, it says it's using __memsetDouble.

> @StevenSchveighoffer also suggested using `memset` (as well as `memcpy`) 
> please correct me if I am wrong but it looks as if `memset` can only 
> write from an `int` sized source and I need the source size to be any 
> potential size (T).

Again, the compiler uses whatever tools are available. It might be 
memset, it might be something else.

In the case of your code, it's using __memsetDouble, which I have no 
idea where it's defined (probably libc).

> ----------------------------------------------------------------------
> On a related aside I noticed that the timing was reduced across the 
> board so much so that the initial slice time halved when initialising with:
> ```
> auto arr = (cast(T*)GC.malloc(T.sizeof*n, GC.BlkAttr.NO_SCAN | 
> GC.BlkAttr.APPENDABLE))[0..n];
> ```
> Instead of:
> ```
> auto arr = new T[n];
> ```

What this means is, don't scan the block for pointers during a GC 
collect cycle. If you have pointers in your T, this is a very bad idea. 
Not only that, but this does not initialize the appendable data at the 
end of the block.

In addition, GC.malloc just zero-initializes the data. If you do new 
T[n], and T has an initializer, it's going to be a lot more expensive.

If you are going to use this, remove the GC.BlkAttr.APPENDABLE.

In the case of double, it is initialized to NaN.

This could explain the difference in timing.

> I noticed that `GC.malloc()` is based on `gc_malloc()` which gives the 
> bit mask option that makes it  faster than `core.stdc.stdlib: malloc`. 
> Is `gc_malloc` OS dependent? I can't find it in the standard C library, 
> the only reference I found for it is 
> [here]( and it is named slightly 
> differently but appears to be the same function. In `core.memory`, it is 
> specified by the `extern (C)` declaration 
> ( so I 
> guess it must be somewhere on my system?

It's in the D garbage collector, here:

extern(C) functions can be implemented in D. The major difference 
between standard D functions and extern(C) is that the latter does not 
do name mangling.


More information about the Digitalmars-d-learn mailing list