Thanks to the ecx-benchmarks, I’ve been prodded to finally start optimizing Eskimo. The API had been stable and working nicely, and I’m comfortable with the overall structure.
So far, I have upgraded Eskimo performance nearly 100x. The ecx-benchmarks had made a special case for Eskimo because of its slow speed, and it could reach roughly 1.8k operations / second. Eskimo now can run 180k operations / second, and with some available optimizations can reach 200k operations / second. I just noticed this myself, but 1 operation is processing 1000 entities, and performing some simple additions.
I’m really happy with these results, but the new API is a bit confusing, and doesn’t guarantee that the user will use the fastest methods in accessing components.
Good-bye Entity. Originally I have always preferred this approach, but at the time I was so used to having an Entity wrapper class. With the optimized code in place, I have a clear vision to remove the Entity wrapper class, using pure Integers in Entity processing. This will eliminate the component access helpers in the Entity class, which were terribly slow. In contrast, the only ways to access components will guarantee optimized access, as well as iterating over entities will be faster. After this refactor, the performance should be guaranteed to be the fastest possible, at all times.
I had a bit of trouble accepting this decision, since Eskimo was meant to be simple and usable. But the Entity wrapper helpers aren’t worth it, and in fact, encourage an “improper” way of thinking about entities as well. I think eliminating the wrapper class is the right decision in the long run.
You can check out the new branch at: Eskimo Next