Performance improvements

[dsaltares]

This is a call to all Ashley contributors. After all this bug fixing it seems we have a pretty stable, easy to use ECS. Now it's time to focus on performance.

Any performance improvement PRs will be most welcome, especially if they do not change the API and do not add any extra complexity to our users.

Thanks!

[junkdog]

I looked around a bit at iteration speed: a pretty big perf gain could likely be gained by refactoring component storage:

Currently each entity maintains its own components. During system processing, for every involved component type (small number), the component has to be individually returned by each entity (a much higher number).

It would involve much less indirection if, for example, the Engine tracked all components:

// one Bag per component type
Bag<SampleComponent> sampleComponents = Bag<SampleComponent>();
// i'm not sure, but I think entities id:s are never recycled?
// maps to entities by some recycled id
SampleComponent sc = sampleGomponents.get(entity.getId());

// on the top level, a Bag of "bag-of-components"
Bag<T> = (Bag<T>)componentsBag.get(componentType.getIndex());

ComponentMappers would greatly benefit from this design, as each mapper would hold onto the bag-of-components it's acting on.

[dsaltares]

That sampleComponents.get(entity.getId() would need to be a dictionary lookup whereas now it's an direct array access. Ids are longs and can be arbitrarily high, so we cannot have a sparse array indexed by those.

If you think it would be faster, it'd be awesome if you could provide some benchmark comparison to back it up.

I like the ideas though, keep them coming!

[junkdog]

That sampleComponents.get(entity.getId() would need to be a dictionary lookup whereas now it's an direct array access. Ids are longs and can be arbitrarily high, so we cannot have a sparse array indexed by those.

Yeah, would need a separate recycled int for entity index in the component bags.

If you think it would be faster, it'd be awesome if you could provide some benchmark comparison to back it up.

I'll see if I cook something up in the next few days, still suffering from an unmitigated man-cold. Shouldn't take too long to test though.

[dsaltares]

Sounds like a plan!

[dsaltares]

If you see the commit history, we have introduced a few performance improvements already. This is a continuous effort.

Are you having any performance related problems in particular?

[mortalisk]

I took a look at the ComponentMapper. I must admit I struggled to see what it is doing that improves performance.

[dsaltares]

It looks-up components from entities using the component bit id, which results in O(1) complexity.

[chartinger]

As I understand a mapper only improves the speed if assignedComponentTypes has to grow when calling ComponentType.getFor (Resulting in O(log(n)) on the first access to the component) is this correct (following get calls should be O(1) in a cuckoo hash map)?

[hexaron]

Hey I'm pretty new to this stuff but when I looked inside the update method of the engine I saw this line:
ImmutableArray<EntitySystem> systems = systemManager.getSystems();
Wouldn't it be faster to only update the ImmutableArray in the add and remove system method instead of updating it every tick? Because I think that adding or removing systems happens less frequently.
Correct me if my idea makes no sense.