Data-Oriented Design (DOD) & C-Distillation Strategy

Status: Deferred (For post-PoC performance optimization)

Context

During the PoC phase, the physical assets (WorldEnv, BodyAsset) utilize std::map<std::string, ...> and object-oriented tree structures. This prioritizes debuggability and human-readable identifiers (e.g., querying "STAGE_1" directly). However, in high-frequency RK4 integrations (1000Hz+), STL maps and nested vectors cause Cache Misses and severe overhead, particularly in Debug builds with iterator bounds checking.

The RuntimeTables Architecture

When migrating to the final embedded system or high-performance simulation core (C-Distillation), the architecture must shift to Data-Oriented Design (DOD).

Core Principles

1. Zero Strings at Runtime: All semantic addressing (e.g., "icu_stage_1", "COMPOSITE_FLIGHT_STACK") is stripped out by an Assembler during the initialization phase.
2. Flattened Arrays:

   // C-Distilled structure example
   struct RuntimeTables {
       // Flat array of all engines across all bodies
       EngineData* engines;       // size: total_num_engines
       // Flat array of all rigid bodies
       BodyMassData* bodies;      // size: total_num_bodies
       // Mapping: Which engines belong to which body?
       uint16_t* body_engine_start_idx;
       uint16_t* body_engine_count;
   };

3. O(1) Execution: The Thrust and Aero pipelines loop through contiguous memory blocks. There are no pointer jumps (std::shared_ptr) or hash map lookups.

The Role of Assembler

The Assembler acts as a compiler. It reads the user-friendly YAMLs (with strings and hierarchies) and "compiles" them into the flat RuntimeTables memory block before the simulation loop begins. This guarantees immutability and memory localization.