Recency biased compaction of variable length records
- Due to the nature of how this architecture handles fields allocation in runtime, only fields that change in size frequently cause a reorganization process.
When a field does change in size it is appended to the end of the buffer, only fields in front of the buffer require a offset calculation.
![[Pasted image 20260119162151.png]]
2. Not all data has to be shifted in runtime, only data that changes in byte length. The complexity model is O(K) where k is all the fields being effected, where not shifting every field, just the fields in front of the changed field.
3. You can have O(1) indexing by taking advantage of frequency, temporal locality and handle usage.Lets say you had entity with a health field, because we know this data will never change in size we can position first in the buffer before any frequently morphing fields, we can store its handle, a handle is just a index .
const player = struct {
health_handle : usize;
run_speed_handle : usize;
core : DynamicCore
}
try player.core.setField("health", @as(i32, 500), allocator);
player.health_handle = player.core.findFieldIndex("health");
// or health can be returned from the setField() procedure.
current health = player.core.getFieldByIndex(player.health_handle);