Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Caching in Queries #4

Open
lukasturcani opened this issue Apr 14, 2023 · 0 comments
Open

Caching in Queries #4

lukasturcani opened this issue Apr 14, 2023 · 0 comments

Comments

@lukasturcani
Copy link
Owner

If you have a two systems

def system_1(q: ecs.Query[tuple[One, Two]]) -> None:
   ...

def system_2(q: ecs.Query[tuple[One, Two]]) -> None:
    ...

They do not both have to perform the query. The application should recognize that both systems require the same entity ids. This can be addressed by:

  • When a query is added to RustApp, it's ID should be some kind of hash of it's component ids.
  • Queries should implement some kind of internal cache. if it has been run before, and no entities have been added or removed, the previous entity ids should be returned by the query.

There are also more complex cases for caches. For example:

  • A query has been performed. Entities have been added to one component but not the others. The query's cache is still valid.
  • A query has been performed. Entities have been removed from any of the components. The queyr needs to remove all the entities which have been removed from any of the components.
  • A query has been performed. The same entities have been added to all the components. The query can be updated with those entities.

In theory this can be implemented by having a cache on the commands, which registers which entities have been added / removed each spawn / delete. This can be built up until they are able to be added to the query result.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant