If anyone has any questions please don’t hesitate to let me know!

Hi @oldpond ! Yes, of course there is a limit for each app where you will max out your hardware capabilities, but there are a few things in ECSx which can help with this.

First, we’ve kept all data writes and reads in-memory (implemented with ETS) for best performance. With this approach, we get constant-time operations regardless of how large your app’s data layer gets. In my experience, ETS is plenty fast enough, but it’s the complexity of algorithms used in System logic which will bottleneck performance first, so it’s important to optimize this logic as best you can.

Second, the ECSx framework adds very little overhead to its underlying data operations, so the performance should be in-line with existing ETS benchmarks. The main performance concern within ECSx itself, is that Systems are serialized via GenServer (the “Manager”) to avoid race conditions and preserve data integrity per-tick. This means by default, you’re running on a single thread without concurrency. To squeeze the most out of your hardware, it’s important to add concurrency within each individual System, if possible. An example of this would be a System that checks the velocity of each entity and adjusts the position coordinates appropriately. Instead of

• fetch velocity components
• for each entity: fetch position component(s), run the mathematical calculation(s), update position

we ideally add concurrency like:

• fetch velocity components
• split them into batches
• spawn an async process/Task for each batch which does the previous step 2
• System waits for all Tasks to finish before completing

which will ensure all your hardware is being put to use, and should be significantly faster for Systems with expensive logic.

Then there is the ECSx Live Dashboard - this will monitor each System individually, as well as the app’s overall performance, and provide a comparison to the “limit” which would cause slowdown/instability. There is always a hard limit of how much time can be used on computation, because each server “tick” is a set length of time. e.g. a server with tick_rate: 20 will expect to run the System logic 20 times per second, creating a time limit of 50 ms. So if you check the dashboard and see that it takes 45 ms for each tick, you know you’re at the limit, and will need to attempt one of the following before adding more load:

• Lower the tick_rate setting to allow more time per-tick
• Further optimize System logic to reduce the time it takes (adding concurrency may be helpful here, as described above)
• Upgrade the hardware

Hope this helps! If you move forward with ECSx for your use-case, I’d love to hear about it, and happy to answer any further questions you might have.

Very cool!
I will remember to use it if I ever start a personal game project.
Adding first-class support for turn-based mechanics will be very welcomed too.