Closed junkdog closed 10 years ago
It is!?
Yes, performance degradation should be similar to pre-artemis 0.7.0 releases. Too early to say why; could be anything from a small, but important optimization in gdx-artemis to an error - either in the benchmark or in gdx-artemis.
Those benchmark systems are not the most readable!
I thought libGDX's Array was the culprit. But I'm not sure.
Its initialized with the default constructor, which sets the Array instance as "ordered". Now, this isn't always checked. When an Entity is added, its just appended at the end of the array. But when it is removed, it uses "removeValue", which, since the Array is set as ordered, removes the Entity and shifts element to the left.
It might retain certain ordering IF the entities are added in order, but gdx-artemis ID pool isn't ordered, so it won't always return the lowest available ID for new entities.
libGDX's Bits might be more efficient than JDK's BitSet, which would influence EntitySystem checks for iteration of bits for removal of components, among other things.
That's all I can think of for now...
Bag and libgdx's Array should perform similarly, including the unordered stuff + they both do deletion by comparing instance identity.
Bits might be faster, but that much faster? If so, BitSet should be at the top of the list when profiling, which isn't the case.
Going to profile it in the coming days, something genius or fishy is going on. Can't tell which.
Bag and libgdx's Array should perform similarly, including the unordered stuff + they both do deletion by comparing instance identity.
Actually, Array should perform worse if ordering influence is discarded. Removal shifts elements through an System.arraycopy call. Which is fast, but not as fast as just swapping with the last element as Bag does.
Bits might be faster, but that much faster? If so, BitSet should be at the top of the list when profiling, which isn't the case.
I don't think it could make such a difference, but maybe costs propagate to ComponentManager while removing the components of the entity. Small enough to not to be picked up by a sampler, big enough to influence surrounding methods. Still it has like 10x the throughput of artemis-odb 0.4.0, which doesn't makes any sense given both do linear search to remove elements and don't strive to keep ordering.
In any case, does gdx-artemis pooling comes into play here? It pools entities and components by default, although entity mangler system seems to create components through reflection. Wouldn't those end up accumulating in gdx-artemis's pool or something? That actually should lower its results...
Turns out entities aren't inserted into systems; weird. I'll probably just remove the benchmark for gdx-artemis in the future, as it's no longer actively maintained and this feels more and more like a bug in their implementation.
That was... unexpected.
A feature ;)
Posted an issue on their tracker.
Nb. Have you done the same sanity check on the ODB results? ;) ODB is basically outperforming a framework that does no system injection.
Nope... and now I got worried ;)
gdx-artemis performs the check() though, which eats up performance.
On Thu, Sep 25, 2014 at 10:07 AM, Daan van Yperen notifications@github.com wrote:
Nb. Have you done the same sanity check on the ODB results? ;) ODB is basically outperforming a system that does no system injection.
— Reply to this email directly or view it on GitHub https://github.com/junkdog/artemis-odb/issues/182#issuecomment-56786913.
0.7.0 can forgo the bitsets completely, as it uses Archetypes for instancing entities. Bitset fiddling is only performed once per system * archetype instance.
Looking at the code, I don't see any radical changes over original artemis.