ecs_benchmark VS artemis-odb

I guess he/she didn't (well, at least judging by the very chatty tone typical of the I would do it better devs), although someone did it for us already if you're interested (for EnTT and for many other libraries too).

As a benchmark, I am currently using Flecs, Legion and others like EnTT and all benchmarks are allocating data sequentially to get cache locality ... How could I not do the same? 😉

Yes, I've already taken a look at those benchmarks, and I'd say it looks like the Retinazer's overall performance is better than Artemis. At this moment, I'm comparing my performance progress against Flecs or other system language ECS like EnTT, which are considered the benchmark.

This is not a real benchmark, but if you could translate this to use your library, then that'd be a decent starting point. It's a few systems and components. The benchmark should be testing how fast you can update 1 million entities. The code in the playground link is based on this C++ ECS library comparison, specifically this file.

Probably this https://github.com/junkdog/artemis-odb

To my knowledge Artemis-Odb ( https://github.com/junkdog/Artemis-odb ) is one of the faster Java ECS implementations. It might be fun and interesting to benchmark against it. Although Artemis-Odb has a different and larger scope and is probably not fully comparable.

I've tinkered with Artemis-odb in a libgdx project, but its honestly starting to feel bloated. I've also tried Ashley, but Artemis seems to be the gold standard for java ECS. It could use a good contender to shake things up.

Modern fork of it for those who are curious: https://github.com/junkdog/artemis-odb

In artemis there is the same concept, with ComponentMapper, maybe can help you: https://github.com/junkdog/artemis-odb/blob/develop/artemis-core/artemis/src/main/java/com/artemis/ComponentMapper.java