Entity Events. Round 2. #2835
Labels
A-ECS
Entities, components, systems, and events
C-Feature
A new feature, making something new possible
S-Needs-Design-Doc
This issue or PR is particularly complex, and needs an approved design doc before it can be merged
In #2070 was proposed following mechanism:
While working on Small Buffer Optimized version of https://github.com/tower120/rc_event_queue / bevyengine/rfcs#32 for experimental implementation of this, I found following:
So... I come to the idea, that if we will fetch components from Sequential Storage by EntityId, in the order they lay in storage - we still should benefit from linear memory access.
The idea is - to have
EventQueue<(EntityId, EventMessage)>
attached to each archetype_storage/table, and haveEventQueue
queue "sorted" by Entity index in correspondent archetype storage. So, in the end, readers will read storage as linear as possible. More over, systems that emit event messages, will most certainly, do this in the order they iterate storage - hence emitted messages should already be mostly sorted(!).In order to reduce overhead from "sorting", we could temporary store
Vec<(EntityId, EventMessage)>
for each event writing system. Sort each of them (they probably will be in sorted state already), and then, at some point (end of the stage?), push messages from vecs in a sorted way (pop_front vec with min first entity index) into EventQueue.The text was updated successfully, but these errors were encountered: