Optimize dropping in bevy_ecs #2897
Closed
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
TheRawMeatball
added
A-ECS
DJMcNab
approved these changes
Oct 1, 2021
| // SAFETY: The pointer points to a valid array of type `[T; len]` and it is safe to drop this value. | ||
| unsafe fn drop_multiple<T>(x: *mut u8, len: usize) { | ||
| for i in 0..len as isize { | ||
| x.cast::<T>().offset(i).drop_in_place() |
There was a problem hiding this comment.
Why is this not a free function in the blob_vec module?
It's repeated here and as an associated function of ComponentDescriptor
| // SAFETY: The pointer points to a valid array of type `[T; len]` and it is safe to drop this value. | ||
| unsafe fn drop_ptr_multiple<T>(x: *mut u8, len: usize) { | ||
| for i in 0..len as isize { | ||
| x.cast::<T>().offset(i).drop_in_place() |
There was a problem hiding this comment.
This should use ptr::add instead, to avoid the isize dance.
bjorn3
reviewed
Oct 1, 2021
| x.cast::<T>().drop_in_place() | ||
| // SAFETY: The pointer points to a valid array of type `[T; len]` and it is safe to drop this value. | ||
| unsafe fn drop_ptr_multiple<T>(x: *mut u8, len: usize) { | ||
| for i in 0..len as isize { |
There was a problem hiding this comment.
Maybe write a manual while loop here instead? That produces less LLVM ir and as such is probably a bit faster in debug mode and takes a bit less time to compile. (all tiny bits help) If you think that is too ugly, it is fine to keep it as is though.
|
Are we certain that this is actually a problem that needs fixing? Has anyone benchmarked this or looked at the generated assembly? |
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.
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.
alice-i-cecile
added
the
S-Needs-Benchmarking
|
@TheRawMeatball if you're up for it, benchmarks on this would be great. If you're busy with other stuff just let me know and we can mark this as abandoned for someone else to experiment with. |
TheRawMeatball
added
the
S-Adopt-Me
SkiFire13
reviewed
May 30, 2022
Comment on lines
+143
to
+145
| for i in 0..len as isize { | ||
| x.cast::<T>().offset(i).drop_in_place() | ||
| } |
There was a problem hiding this comment.
Couldn't this just be std::slice::from_raw_parts_mut(x.cast::<T>(), len).drop_in_place()?
There was a problem hiding this comment.
It did have to be the std::ptr:: counterpart, but i think that could work.
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.
|
Adopted! |
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.
Previously, the type-erased drop impl was for dropping a single element, which meant a large number of fn pointer calls and having to iterate each component even for no-op drops. This PR moves the iteration to the generic part, which should enable noop drops to get optimized much further.