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 |
GC.BlkAttr.APPENDABLE))[0..n];
```
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](https://linux.die.net/man/3/gc) and it is named
slightly differently but appears to be the same function. In
`core.memory`, it is specified by the `extern (C)` declaration
(https://github.com/dlang/druntime/blob/master/src/core/memory.d)
so I guess it must be somewhere on my system?
Thanks
