dconf dod parser is 20% slower thoery

[monkyyy]

On Friday, 18 July 2025 at 08:53:23 UTC, Robert Schadek wrote:
> 
> SumType

> struct Parser {
>   Nodes[] nodes;

Im still seeing an extra layer of indirection.

consider int[100], int[] and int[int] and the data 1->3, 3->2, 
2->4, 4->(-1)

the ideal is int[100], it will allocate either on the stack or 
global scope fast has as possible and indexing it should always 
be inlinable, and I trust even the dumbest prefetcher to see "oh 
a 1 wants to see[3]"

int[int] is far from ideal but the hash maybe the prefetcher 
decides to untangle it and I imagine you used it in places for 
your nondata oriented way

int[] has 3 pieces that needs to be calculated at runtime 
`int[].ptr`, `int[].length` and `int[3]`, the pefetcher has to a) 
think that "3 is probably in that" b) the asm has to have a 
int[].ptr registor, taking up some cache line d) the prefetcher 
has to be able to combine `(int[].ptr + 3*int.sizeof)` which may 
as well be the hash of the hashtable thats math with several 
steps, e) then a swap context to druntimes assert(3<int[].length) 
f) then swap back

---

int[] is fast enough *as an range* because it has 2 iterations to 
find [0] but then its ++ing while checking a length, an ancient c 
for loop, the aa's are likely better for trees unless you go all 
the way

---

You have a big old block of memory, put it in a big static array 
or inline void* math for it to be data oriented design

Im struggling with getting it to work with you know none of my 
dips ever being accepted espeally none of the meta programming 
ones(my current best solution is opend dependent); but I think 
youd need a pattern of structs that accept pointer abstractions 
from an array

```d
struct foo(P){
    ...
    P left;
    P right;
}
struct array(alias T,int N){
   alias P=...
   T!P[N] data;
   ...
}
array!(foo,100) bar;
```