Closed quetzalsly closed 2 years ago
The optimizations implemented in the fork are not directly related to ECS.
The original dod-playground
sample used a brute-force approach to test each entity with each other entity, while fork author implemented a grid-based solution that allows to skip testing entities that are far away from each other. In other words, the fork author came up with a clever way of doing several orders of magnitude less work and you are comparing apples to oranges here.
If you compare the unit test performance to the original dod-playground
(they both seem to have almost identical code) you will see very similar results. In fact I just tried it, and they both run at ~22ms on my PC in Release mode with 1 million entities. If you implement a similar grid-based optimization in the unit test, you will likely get similar performance improvements.
On top of that, the fork behavior is not equivalent to the original implementation, which further invalidates all performance improvement claims.
Thanks for the info, did you test the-forge against dod original repo then?
Yes I compared the-forge unit test to the original dod-playground
repo. This is a very approximate comparison and still "apples to oranges" to some extent, so keep that in mind 😄
I think we can close this?
I did a quick benchmark between:
Unit_Tests/17_EntityComponentSystem https://github.com/AlexSabourinDev/dod-playground (faster fork of original)
Both tests compiled on same computer, the-forge is vulkan and dod is d3d11. Both are using 1 million sprites + 20 bubbles.
Release mode: dod = 8ms per frame, the-forge = 150 ms per frame Debug mode: dod = 15ms per frame, the-forge crashed
This is on windows 7, ofcourse the projects are vastly different, one is a sample app and the other is a whole framework, but still I was expecting to see closer results.
If someone is able to run this on windows 10 and with different renderers please post your results, thanks.