[Merged by Bors] - Skip drop when needs_drop is false
#4773
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
DJMcNab
added
C-Feature
bjorn3
suggested changes
May 16, 2022
DJMcNab
commented
May 16, 2022
| } | ||
| { | ||
| #[cfg(feature = "trace")] | ||
| let _stage_span = |
There was a problem hiding this comment.
@bjorn3 I've left this in for now, as I'm struggling to find a compelling argument for running Cleanup and clearing the entities to have no differentiation. Perhaps it should be nested, but that's a different question to what you were requesting.
james7132
approved these changes
May 16, 2022
There was a problem hiding this comment.
LGTM other than the existing review comments. I was a bit suspicious of adding a branch in the hotpath for deleting/moving entities around, but it makes sense that a branch would be preferable to what is effectively a virtual function call that POD components don't use.
bjorn3
approved these changes
May 16, 2022
james7132
added
the
S-Ready-For-Final-Review
alice-i-cecile
approved these changes
May 16, 2022
Co-authored-by: Alice Cecile <[email protected]>
|
bors r+ |
bors bot
pushed a commit
that referenced
this pull request
May 17, 2022
# Objective - We do a lot of function pointer calls in a hot loop (clearing entities in render). This is slow, since calling function pointers cannot be optimised out. We can avoid that in the cases where the function call is a no-op. - Alternative to #2897 - On my machine, in `many_cubes`, this reduces dropping time from ~150μs to ~80μs. ## Solution - Make `drop` in `BlobVec` an `Option`, recording whether the given drop impl is required or not. - Note that this does add branching in some cases - we could consider splitting this into two fields, i.e. unconditionally call the `drop` fn pointer. - My intuition of how often types stored in `World` should have non-trivial drops makes me think that would be slower, however. N.B. Even once this lands, we should still test having a 'drop_multiple' variant - for types with a real `Drop` impl, the current implementation is definitely optimal.
bors
bot
changed the title
drop when needs_drop is falsedrop when needs_drop is false
robtfm
pushed a commit
to robtfm/bevy
that referenced
this pull request
May 17, 2022
# Objective - We do a lot of function pointer calls in a hot loop (clearing entities in render). This is slow, since calling function pointers cannot be optimised out. We can avoid that in the cases where the function call is a no-op. - Alternative to bevyengine#2897 - On my machine, in `many_cubes`, this reduces dropping time from ~150μs to ~80μs. ## Solution - Make `drop` in `BlobVec` an `Option`, recording whether the given drop impl is required or not. - Note that this does add branching in some cases - we could consider splitting this into two fields, i.e. unconditionally call the `drop` fn pointer. - My intuition of how often types stored in `World` should have non-trivial drops makes me think that would be slower, however. N.B. Even once this lands, we should still test having a 'drop_multiple' variant - for types with a real `Drop` impl, the current implementation is definitely optimal.
exjam
pushed a commit
to exjam/bevy
that referenced
this pull request
May 22, 2022
# Objective - We do a lot of function pointer calls in a hot loop (clearing entities in render). This is slow, since calling function pointers cannot be optimised out. We can avoid that in the cases where the function call is a no-op. - Alternative to bevyengine#2897 - On my machine, in `many_cubes`, this reduces dropping time from ~150μs to ~80μs. ## Solution - Make `drop` in `BlobVec` an `Option`, recording whether the given drop impl is required or not. - Note that this does add branching in some cases - we could consider splitting this into two fields, i.e. unconditionally call the `drop` fn pointer. - My intuition of how often types stored in `World` should have non-trivial drops makes me think that would be slower, however. N.B. Even once this lands, we should still test having a 'drop_multiple' variant - for types with a real `Drop` impl, the current implementation is definitely optimal.
ItsDoot
pushed a commit
to ItsDoot/bevy
that referenced
this pull request
Feb 1, 2023
# Objective - We do a lot of function pointer calls in a hot loop (clearing entities in render). This is slow, since calling function pointers cannot be optimised out. We can avoid that in the cases where the function call is a no-op. - Alternative to bevyengine#2897 - On my machine, in `many_cubes`, this reduces dropping time from ~150μs to ~80μs. ## Solution - Make `drop` in `BlobVec` an `Option`, recording whether the given drop impl is required or not. - Note that this does add branching in some cases - we could consider splitting this into two fields, i.e. unconditionally call the `drop` fn pointer. - My intuition of how often types stored in `World` should have non-trivial drops makes me think that would be slower, however. N.B. Even once this lands, we should still test having a 'drop_multiple' variant - for types with a real `Drop` impl, the current implementation is definitely optimal.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
many_cubes, this reduces dropping time from ~150μs to ~80μs.Solution
dropinBlobVecanOption, recording whether the given drop impl is required or not.dropfn pointer.Worldshould have non-trivial drops makes me think that would be slower, however.N.B. Even once this lands, we should still test having a 'drop_multiple' variant - for types with a real
Dropimpl, the current implementation is definitely optimal.