Add common component conditions - #7711
Conversation
alice-i-cecile
left a comment
There was a problem hiding this comment.
Otherwise this check could be expensive and hold up the executor preventing it from running any systems during the check.
I think this can be more clearly phrased by replacing your warning with the following:
Run conditions are evaluated on the main thread, blocking any other systems from running.
This run condition is relatively expensive, as it iterates over every entity with this component.
As a result, you likely only want to use this run condition when the number of entitities with the componentTis small.
One more request: can we have the same flavor of run condition, but for RemovedComponent<T>?
I like it!
I think we switched to events for this: #5680 |
That PR was effectively non-breaking :) The |
Right, missed that it was an internal change. Will add the condition. |
We probably should add |
037bc82 to
749a42b
Compare
| /// This run condition is relatively expensive, as it iterates over every entity with this component. | ||
| /// As a result, you likely only want to use this run condition when the number of entitities with the component `T` is small. | ||
| pub fn any_component_added<T: Component>() -> impl FnMut(Query<(), Added<T>>) -> bool { | ||
| move |query: Query<(), Added<T>>| !query.is_empty() |
There was a problem hiding this comment.
These potentially do a full world scan in the multithreaded executor, which not only runs single threaded but blocks any further system's run conditions from being evaluated and tasks launched. The only early return is if no archetypes match the query, everything else does a full scan, and will scale linearly with the number of those components in the world. This is relatively easy performance footgun, same with the other condition below.
Even with it documented, I still don't think it's a good idea to readily provide this to users without some form of archetype-level change detection optimization.
There was a problem hiding this comment.
Yep, this is what I mentioned in the description. I thought it's fine if documented. But your concern is exactly why it wasn't included in #7579.
Co-authored-by: Ida "Iyes" <40234599+inodentry@users.noreply.github.com>
inodentry
left a comment
There was a problem hiding this comment.
Suggesting better wording for the doc comments!
Co-authored-by: Ida "Iyes" <40234599+inodentry@users.noreply.github.com>
Co-authored-by: Ida "Iyes" <40234599+inodentry@users.noreply.github.com>
|
Thanks! |
|
Other than the little things I pointed out above, I approve! Given the warning in the documentation, I think this is worth including in Bevy. As implemented, if, in the future, change detection gets optimized so that the queries don't have to iterate, this API will just magically become fast, and we can remove the perf warning. :) |
Added helper extracted from #7711. that PR contains some controversy conditions, but this one should be good to go. --- ## Changelog ### Added - `any_component_removed` condition. --------- Co-authored-by: François <mockersf@gmail.com>
|
I moved non-controversial |
|
It was decided to not implement it, closing. |
Add two useful common run conditions for components similar to
any_with_componentfrom #7579. Unlikeany_with_componentthese two conditions could be potentially expensive, but super useful if user knows that there is only a few entities with a component.Changelog
Added
any_component_addedandany_component_changed.