4 ms·
I wonder how well SQLite would just handle this whole thing. Seriously. Compile a bunch of prepared statements at load time to take the parsing and execution
by claytongulick 3y ago
I wonder how well SQLite would just handle this whole thing.
Seriously.
Compile a bunch of prepared statements at load time to take the parsing and execution planning out of it, keep it all in memory... On the surface it seems like it would work.
And of course, saving the entire game state would be as simple as just flushing the DB to disk.
- kitd 3y agoOne of the reasons for using an ECS is cache coherence. All your game state is lumped together in one chunk or memory. Lookup times are near instant as a result. Moving to SQLite makes theoretical sense, but you lose the benefit of cache coherence as a result. Though you probably do gain other benefits.
- claytongulick 3y agoI'm not familiar with the guts of SQLite enough to say, but wouldn't this be true for an in-memory database too, if you structured the "tables" properly? Also, I'm not sure I understand how cache coherence would be relevant in the context of what the article is discussing, querying across all game entities to answer complex questions. Wouldn't cache coherence matter more in the case of single object access?
- ajmmertens 3y agoThe query engine works on top of an Entity Component System (ECS) storage that stores entities and their data in cache coherent (SoA - https://en.wikipedia.org/wiki/AoS_and_SoA https://en.wikipedia.org/wiki/AoS_and_SoA) data structures. With any kind of database - even in-memory SQLite - there is a query interface between you and the data. In ECS you access data directly, which is at least an order of magnitude faster.