Array fill performance differences between for, foreach, slice

data pulverizer data.pulverizer at
Wed Apr 1 15:23:41 UTC 2020

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.

@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).


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 | 

Instead of:

auto arr = new T[n];

If I am filling the array with something anyway for example 
`arr[] = x` is there anything wrong with this approach? Should I 
care if the memory is not "scanned" - I have no idea what that 
means but I assume it's some kind of check that takes time and is 
switched off by `GC.BlkAttr.NO_SCAN`. Are there any downsides to 
this that I should be aware of?

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?


More information about the Digitalmars-d-learn mailing list