Skip to content
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

Memory usage of camera bundles #6417

Closed
eyzi opened this issue Oct 30, 2022 · 1 comment
Closed

Memory usage of camera bundles #6417

eyzi opened this issue Oct 30, 2022 · 1 comment
Labels
A-Rendering Drawing game state to the screen C-Bug An unexpected or incorrect behavior C-Performance A change motivated by improving speed, memory usage or compile times

Comments

@eyzi
Copy link

eyzi commented Oct 30, 2022

Bevy version

0.8.1

Relevant system information

cargo version: cargo 1.64.0 (387270bc7 2022-09-16)
OS: Windows 11 (build 22621.674)

`AdapterInfo { name: "NVIDIA GeForce GTX 980 Ti", vendor: 4318, device: 6088, device_type: DiscreteGpu, backend: Vulkan }`

What you did

Running a bare project with only DefaultPlugins and a camera bundle (tested with both 2d and 3d)

#![windows_subsystem = "windows"]

use bevy::prelude::{App, Camera2dBundle, Commands, DefaultPlugins};

fn main() {
    App::new()
        .add_plugins(DefaultPlugins)
        .add_startup_system(setup_camera)
        .run();
}

fn setup_camera(mut commands: Commands) {
    commands.spawn().insert_bundle(Camera2dBundle::default());
}

What went wrong

I noticed that the memory usage of my builds (with cargo build --release and without console) is steadily growing. While troubleshooting for the root cause, I ended up just running a bare project (see above code) in which I was able to reproduce the behaviour. It seems like the camera bundles, both Camera2dBundle::default() and Camera3dBundle::default() are using the RAM increasingly with time. Roughly about 8Kb per second of usage growth for Camera2dBundle and 12Kb per second for Camera3dBundle.

When tried without the camera bundles, the memory usage is fairly stable.
When tried with a running game loop, there's not much difference in usage increase, if at all.
In debug, memory usage increases a lot faster.
In release with console, memory usage increases at about the same rate.

Additional information

Brought this up on Discord's help forum and was advised to create an issue as there might be a memory leak somewhere.

@eyzi eyzi added C-Bug An unexpected or incorrect behavior S-Needs-Triage This issue needs to be labelled labels Oct 30, 2022
@alice-i-cecile alice-i-cecile added A-Rendering Drawing game state to the screen C-Performance A change motivated by improving speed, memory usage or compile times and removed S-Needs-Triage This issue needs to be labelled labels Oct 30, 2022
@hymm
Copy link
Contributor

hymm commented Nov 2, 2022

Tested this and I was able to reproduce on Windows 11.

main branch also seems to have this problem but grows more slowly at like like 2Kb/s with Camera2dBundle

@bors bors bot closed this as completed in 75880a0 Dec 11, 2022
alradish pushed a commit to alradish/bevy that referenced this issue Jan 22, 2023
# Objective

- Fixes bevyengine#6417

## Solution

- clear_trackers was not being called on the render world. This causes the removed components vecs to continuously grow. This PR adds clear trackers to the end of RenderStage::Cleanup

## Migration Guide

The call to `clear_trackers` in `App` has been moved from the schedule to App::update for the main world and calls to `clear_trackers` have been added for sub_apps in the same function. This was due to needing stronger guarantees. If clear_trackers isn't called on a world it can lead to memory leaks in `RemovedComponents`.
ItsDoot pushed a commit to ItsDoot/bevy that referenced this issue Feb 1, 2023
# Objective

- Fixes bevyengine#6417

## Solution

- clear_trackers was not being called on the render world. This causes the removed components vecs to continuously grow. This PR adds clear trackers to the end of RenderStage::Cleanup

## Migration Guide

The call to `clear_trackers` in `App` has been moved from the schedule to App::update for the main world and calls to `clear_trackers` have been added for sub_apps in the same function. This was due to needing stronger guarantees. If clear_trackers isn't called on a world it can lead to memory leaks in `RemovedComponents`.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-Rendering Drawing game state to the screen C-Bug An unexpected or incorrect behavior C-Performance A change motivated by improving speed, memory usage or compile times
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants