Help optimizing Aztecs - an ECS now using sparse sets

Learn
1

Hey :wave: I’ve been working on getting mutable sparse sets (based on vectors) working as the backing data structure for Aztecs GitHub - aztecs-hs/aztecs: A modular game engine and ECS for Haskell.

I’m really struggling getting closer to other ECS frameworks like Apecs, Bevy, or Flecs. I totally accept Haskell may bring some overhead, especially when mimicking the imperative style of a Rust or C++ ECS, but I feel like my current results have to include some low-hanging fruit… :thinking: I’d absolutely love any help making this ECS faster!

The new sparse set data structure is heavily based off EnTT and Bevy’s versions GitHub - aztecs-hs/sparse-set: An efficient sparse-set data structure for Haskell. At the lower level, this is based on GitHub - aztecs-hs/sparse-vector: Sparse n-dimensional vectors for Haskell, which is basically just a Vector (Maybe a) that provides an API similar to IntMap.

I’ve been able to get queries for 10,000 entities (with two components) down to about 700us on my machine, where the previous immutable IntMap solution was about 100us. Bevy is still blowing this out of the water at about 8us :eyes:

1 Like
2

I’m afraid Vector (Maybe a) is doomed to be slow. For performance you want to replace Maybe a with (Bool, a), so that you have a bit vector and then Vector a, potentially unboxed if a allows it.

5 Likes
3

Do you mean MVector?
You don’t mention what operations you use, but with a Vector modifications will be slow, unsurprisingly, because it needs to copy all the elements into a new Vector.

1 Like
4

You can look at my code here for inspiration (or simply copy it):

I think my code should be reasonably fast. Keep in mind that the Storable version is simply the best for performance. You will never beat it with a boxed approach.

2 Likes