-
-
Notifications
You must be signed in to change notification settings - Fork 3.6k
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
Inefficient use of Vec::push in prepare_uniform_components function #8284
Comments
You may be interested in weighing in on #8204 |
@CrazyRoka turns out the |
@james7132 Thank you for your PR to improve Bevy performance. I have 2 more questions:
|
I used Tracy and the
Batch insertion probably is for the best here. We need to construct both the buffer and the Vec for Commands, and preallocating then skipping the capacity checks likely will have a significant speedup. Though with that said, with dynamic uniform offsets being pessimistically aligned to 256 bytes, we might not see much gain there. |
# Objective This is a minimally disruptive version of #8340. I attempted to update it, but failed due to the scope of the changes added in #8204. Fixes #8307. Partially addresses #4642. As seen in #8284, we're actually copying data twice in Prepare stage systems. Once into a CPU-side intermediate scratch buffer, and once again into a mapped buffer. This is inefficient and effectively doubles the time spent and memory allocated to run these systems. ## Solution Skip the scratch buffer entirely and use `wgpu::Queue::write_buffer_with` to directly write data into mapped buffers. Separately, this also directly uses `wgpu::Limits::min_uniform_buffer_offset_alignment` to set up the alignment when writing to the buffers. Partially addressing the issue raised in #4642. Storage buffers and the abstractions built on top of `DynamicUniformBuffer` will need to come in followup PRs. This may not have a noticeable performance difference in this PR, as the only first-party systems affected by this are view related, and likely are not going to be particularly heavy. --- ## Changelog Added: `DynamicUniformBuffer::get_writer`. Added: `DynamicUniformBufferWriter`.
# Objective This is a minimally disruptive version of bevyengine#8340. I attempted to update it, but failed due to the scope of the changes added in bevyengine#8204. Fixes bevyengine#8307. Partially addresses bevyengine#4642. As seen in bevyengine#8284, we're actually copying data twice in Prepare stage systems. Once into a CPU-side intermediate scratch buffer, and once again into a mapped buffer. This is inefficient and effectively doubles the time spent and memory allocated to run these systems. ## Solution Skip the scratch buffer entirely and use `wgpu::Queue::write_buffer_with` to directly write data into mapped buffers. Separately, this also directly uses `wgpu::Limits::min_uniform_buffer_offset_alignment` to set up the alignment when writing to the buffers. Partially addressing the issue raised in bevyengine#4642. Storage buffers and the abstractions built on top of `DynamicUniformBuffer` will need to come in followup PRs. This may not have a noticeable performance difference in this PR, as the only first-party systems affected by this are view related, and likely are not going to be particularly heavy. --- ## Changelog Added: `DynamicUniformBuffer::get_writer`. Added: `DynamicUniformBufferWriter`.
I created a stress test scenario with the Bevy engine (link) where I created 100K entities. I noticed that the
prepare_uniform_components
function was using 4.23% of the CPU time, and upon investigating the code, I found that theVec3::push
method was being called for each of the entities, which is not efficient.To improve performance, I suggest copying all the objects in batches instead of pushing them one by one. Apart from that,
DynamicUniformBuffer::write
can be optimized as well. I am attaching my Flamegraph to this issue.bevy/crates/bevy_render/src/extract_component.rs
Lines 126 to 153 in aefe1f0
The text was updated successfully, but these errors were encountered: