-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
Remove archetype_component_access from QueryState #12474
Remove archetype_component_access from QueryState #12474
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. I always appreciate these simple-in-hindsight optimizations with wide-reaching effects
I'd be interested to see if there's a measurable impact on our benchmarks, or if the savings are mainly for memory and cache usage
I don't really expect them to show up in the microbenchmarks since they all hit the ArchetypeGeneration check, come up empty, and return immediately. Might improve it a little bit by reducing instruction cache pressure a bit by having less codegen though. |
# Objective Other than the exposed functions for reading matched tables and archetypes, a `QueryState` does not actually need both internal Vecs for storing matched archetypes and tables. In practice, it will only use one of the two depending on if it uses dense or archetypal iteration. Same vein as #12474. The goal is to reduce the memory overhead of using queries, which Bevy itself, ecosystem plugins, and end users are already fairly liberally using. ## Solution Add `StorageId`, which is a union over `TableId` and `ArchetypeId`, and store only one of the two at runtime. Read the slice as if it was one ID depending on whether the query is dense or not. This follows in the same vein as #5085; however, this one directly impacts heap memory usage at runtime, while #5085 primarily targeted transient pointers that might not actually exist at runtime. --- ## Changelog Changed: `QueryState::matched_tables` now returns an iterator instead of a reference to a slice. Changed: `QueryState::matched_archetypes` now returns an iterator instead of a reference to a slice. ## Migration Guide `QueryState::matched_tables` and `QueryState::matched_archetypes` does not return a reference to a slice, but an iterator instead. You may need to use iterator combinators or collect them into a Vec to use it as a slice. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>
Objective
QueryState::archetype_component_access
is only really ever used to extendSystemMeta
's. It can be removed to save some memory for everyQuery
in an app.Solution
new_archetype
pass in a&mut Access<ArchetypeComponentId>
instead and pull it fromSystemMeta
directly.QueryState::new
fromQueryState::new_with_access
and a commonQueryState::new_uninitialized
.new_archetype
into an internal and public version. Call the internal version inupdate_archetypes
.This should make it faster to construct new QueryStates, and by proxy lenses and joins as well.
matched_tables
also similarly is only used to deduplicate inserting intomatched_table_ids
. If we can find another efficient way to do so, it might also be worth removing.The generated assembly reflects this well, with all of the access related updates in
QueryState
being removed.Changelog
Removed:
QueryState::archetype_component_access
.Changed:
QueryState::new_archetype
now takes a&mut Access<ArchetypeComponentId>
argument, which will be updated with the new accesses.Changed:
QueryState::update_archetype_component_access
now takes a&mut Access<ArchetypeComponentId>
argument, which will be updated with the new accesses.Migration Guide
QueryState::archetype_component_access
has been removed. This can be worked around by accessing the surroundingSystemState
's instead. If you needed this explicitly forQueryState
, please file an issue.