On 7/10/20 8:03 AM, wjoe wrote:
> What I'm saying is even if this allocation is slow let's say 5ms, but it
> only happens once, that wouldn't matter to overall performance at all.
Yes, you are correct and there are dynamic arrays that are allocated
once in many programs.
I haven't read the rest of your post but you've said elsewhere that a
static array is on the stack. Yes, there are such static arrays but the
issue is not that simple.
struct S {
float[3] rgb; // Can be on the stack or dynamic memory
}
The member of that struct can be anywhere:
void foo() {
S s; // On the stack
auto arr = [ S() ]; // On dynamically allocated memory
}
Additionally, as is common and understandable in D, we are conflating
dynamic arrays and slices. The way I see it is dynamic array is owned by
the D runtime. Although a slice is an interface to such dynamic arrays,
a slice can start its life with non-dynamic arrays and may or may not
move to accessing dynamic arrays.
struct S {
float[] arr; // A slice can use dynamic or static memory
}
void foo() {
float[10] storage;
auto a = S(storage[1..7]); // Slice is referring to the stack space
auto b = S();
b.arr ~= 1.5; // Slice is referring to dynamic memory
}
What is important is overhead:
1) Allocation: Only sometimes an issue.
2) Cost of the slice object (1 pointer and 1 size_t): The cost of this
may be enormous. (Compare the 12-byte rgb above to a 16-byte slice
overhead.)
3) Cost of accessing the elements: The access through that extra level
of indirection may be a cost but the CPU can alleviate it by
pre-fetching or caching but only for some access patterns.
4) Bounds checking: Some bounds checks for static arrays can be elided
at run time.
So, there are cases where a dynamic array is better (or must), there are
cases there is no winner and there are cases where a static array is a
huge win.
Ali
