Seriously WTF is this? Why do we do stuff with a SortedCollisionEvent struct BUT NEVER CALL .sort(). Wild. Ill profile it later. The name on the named for-loop is now extraneous since this function now has 1 for loop. Everything else is now if-statements. Let's talk about what to do next here. Calling .get() is definitely the right move over iteration.
We must take audio out of this function. It is having enough trouble "tagging" collisions and doing dynamic dispatch. There should be an audio effects module that consumes these SortedCollisionEvents
I think this PR removes 20 for-loops.
I have every reason to believe this is faster because:
calling query.get(entity_id) ultimately boils down to an index-based lookup in a Vec<EntityMeta> whereas doing query.iter().filter(|x| x == other_entity) loops through a "sparse array" and checks if "an index is in the dense array", which is almost one of the few things sparse arrays are good for in the first place.
Seriously WTF is this? Why do we do stuff with a
SortedCollisionEvent
struct BUT NEVER CALL.sort()
. Wild. Ill profile it later. The name on the named for-loop is now extraneous since this function now has 1 for loop. Everything else is now if-statements. Let's talk about what to do next here. Calling.get()
is definitely the right move over iteration.We must take audio out of this function. It is having enough trouble "tagging" collisions and doing dynamic dispatch. There should be an audio effects module that consumes these
SortedCollisionEvent
sI think this PR removes 20 for-loops.
I have every reason to believe this is faster because:
calling
query.get(entity_id)
ultimately boils down to an index-based lookup in aVec<EntityMeta>
whereas doingquery.iter().filter(|x| x == other_entity)
loops through a "sparse array" and checks if "an index is in the dense array", which is almost one of the few things sparse arrays are good for in the first place.