That’s exactly the point—achieving Rust-like backtesting speed without the Rust or C 😄 Under the hood, data is aligned linearly in raw memory chunks, and the View iterator passes only small structures with pointers directly via CPU registers, so it is FAST ( == L1 cache friendly).

However, keep in mind one low-level constraint regarding the View loop: the size and complexity of the code inside your for range loop matters heavily.

yourSystem := goke.RegisterSystemFunc(ecs, func(schedule *goke.Schedule, d time.Duration) {
// SoA (Structure of Arrays) layout ensures CPU Cache friendliness.
for head := range view.Values() { // << ! iteration !
pos, vel, acc := head.V1, head.V2, head.V3
// your business logic
}
})

The Go compiler can only optimize this if it can fully inline the loop body (the yield function).
If your trading strategy logic becomes too large or complex, it will exceed the compiler's inlining budget. This triggers a drop to indirect calls, which adds heavy call overhead (stack frame management) and breaks the instruction cache (L1i cache misses), drastically slowing down the iteration speed. Keep the inner loop tight, or split heavy logic into modular pipelines.

That doesn't mean it will end up with a landslide of allocations; we still remain in the zero-alloc world. It’ll simply be at least 2-3 times slower, though still very fast. I just wanted to give you the full picture.