The article basically describes the Entity-Component-System architecture and it makes sense when your app is essentially a stateful simulation with many independent subsystems (rendering, physics, etc.) managing lots of similar objects in realtime (i.e. games). I thought about how it could be used in other contexts (for example, webdev) and failed to find uses for it outside of gamedev/simulation software. It feels like outside of gamedev, with this architecture, a lot of developer energy/focus will be, by design, spent on premature optimizations and infrastructure-related boilerplate (setting up object pools etc.) instead of focusing on describing business logic in a straightforward, readable way. Are there success stories of using this architecture (ECS) outside of gamedev and outside of C++?
It's mostly a linguistic distinction: is your indirection a memory address, or is it relative to a data structure? You gain more than you lose in most instances by switching models away from the machine encoding - ever since CPUs became pipelined, using pointers directly has been less important than contriving the data into a carefully packed and aligned array, because when you optimize to the worst case you mostly care about the large sequential iterations. And once you have the array, the handles naturally follow.
The reason why it wouldn't come up in webdev is because you have a database to do container indirection, indexing, etc., and that is an even more powerful abstraction. The state that could make use of handles is presentational and mostly not long-lived, but could definitely appear on frontends if you're pushing at the boundaries of what could be rendered and need to drop down to a lower level method of reasoning about graphics. Many have noted a crossover between optimizing frontends and optimizing game code.
It’s more the Entity in an ECS is a special case of a handle that references into multiple other containers. Handles in general are used all over the place outside of that context.
ECS are a special case of what the article is about, not the other way around.
For instance, I independently came to the same conclusion than the author while developing a library implementing polytomic tree structures.
It's much easier to handle blck-box NodeID's to the user (techincally u64, but don't tell them ;) and act on them with dedicated functions from the lib rather than clenching your teeth waiting for the inevitable segfault when one plays with pointers.
And it's also much easier to handle for the user: you have handles, functions creating them, functions using them, and the library can gracefully fail if you keep using them the wrong way.
You are conflating object pools and ECS architecture. Yes, they work very well together, but neither is required for the other.
The ECS architecture is about which parts of your application are concerned with what, and it's an absolute godsend for building complex and flexible business logic. I would be loathe to ever use anything else now that I have tasted this golden fruit.
Object pooling is about memory management; in an OO language this is about reducing pressure on the garbage collector, limiting allocation and GC overhead, improving memory access patterns, etc. -- all the stuff he talks about in this article. I almost never use object pools unless I'm running a huge calculation or simulation server-side.
Games use both, because they're basically big simulations.
I write business logic and I use a fair amount of object pooling. It's not quite the same as in game dev or e.g. a socket pool or worker pool where you're constantly swapping tons of things in and out, but it can still be helpful to speed up the user experience, manage display resources and decrease database load.
One example would be endless-scrolling calendar situations, or data tables with thousands of rows, or anything where I'm using broader pagination in the database calls than I want to in the display chain; maybe I can call up 300 upcoming reservations every time the calendar moves, erase the DOM and redraw 300 nodes, but I'd rather call up 3,000 all at once and use a reusable pool of 300 DOM nodes to display them.
Really? The main point (use an index into an array instead of a pointer into a blob of memory) gets you 99% of the benefit and it isn’t anymore difficult than using pointers. I do this all the time.
I think this pattern is also useful for creating tightly performing middleware. However it needs language, compiler and library support to really take off wrt large scale adoption.
Ie, when someone marks gives a `Resource` annotation to a struct, then the compiler also generates a `ResourceHandle` and a `ResourceManager` for you which does all this work. All the internal SoA (structure of arrays work) is handled for you as long as you implement the `ResourceFinalizer` interface (for non trivial resources)
This is not an entity component system.
ECS defines how you need to structure your code.
You have basic entities that you can assign components to.
If you add certain components to entities then some systems will handle logic for all entities that have some subset of components. Entities that do not have the required set of components will be ignored.
ECS can usually benefit from these types of allocators as they provide performance benefits but it isn't required.
