bevyengine / bevyengine/bevy

Bevy depends on 4 different versions of the windows crate

Open
#11,244 9 comments 5 reactions 0 assignees View on GitHub
C-Bug C-Dependencies C-Performance O-Windows
Dominant language
Rust
Stars
48.2k
Forks
4.8k
Avg merge
3d 16h
Merged PRs (30d)
171

Description

## Bevy version

* Original: 0.12.1
* Current: 0.12.1

## Relevant system information

```
❯ cargo --version
cargo 1.77.0-nightly (ac6bbb332 2023-12-26)
```
on windows 10

## What's performing poorly?

This is not necessarily a regression, but it was the template that fits best. Bevy currently depends on 4 versions of the windows crate, namely `0.44.0`, `0.46.0`, `0.48.0` and `0.52.0`:

```
windows v0.44.0
└── gpu-allocator v0.22.0
└── wgpu-hal v0.17.2
├── wgpu v0.17.2
│ └── bevy_render v0.12.1
│ ├── bevy_animation v0.12.1
│ │ ├── bevy_gltf v0.12.1 (*)
│ │ └── bevy_internal v0.12.1 (*)
│ ├── bevy_core_pipeline v0.12.1
│ │ ├── bevy-inspector-egui v0.22.1 (*)
│ │ ├── bevy_gizmos v0.12.1
│ │ │ └── bevy_internal v0.12.1 (*)
│ │ ├── bevy_gltf v0.12.1 (*)
│ │ ├── bevy_internal v0.12.1 (*)
│ │ ├── bevy_pbr v0.12.1
│ │ │ ├── bevy-inspector-egui v0.22.1 (*)
│ │ │ ├── bevy_gizmos v0.12.1 (*)
│ │ │ ├── bevy_gltf v0.12.1 (*)
│ │ │ └── bevy_internal v0.12.1 (*)
│ │ ├── bevy_sprite v0.12.1
│ │ │ ├── bevy_gizmos v0.12.1 (*)
│ │ │ ├── bevy_internal v0.12.1 (*)
│ │ │ ├── bevy_text v0.12.1
│ │ │ │ ├── bevy_internal v0.12.1 (*)
│ │ │ │ └── bevy_ui v0.12.1
│ │ │ │ └── bevy_internal v0.12.1 (*)
│ │ │ └── bevy_ui v0.12.1 (*)
│ │ └── bevy_ui v0.12.1 (*)
│ ├── bevy_gizmos v0.12.1 (*)
│ ├── bevy_gltf v0.12.1 (*)
│ ├── bevy_internal v0.12.1 (*)
│ ├── bevy_pbr v0.12.1 (*)
│ ├── bevy_scene v0.12.1
│ │ ├── bevy_gltf v0.12.1 (*)
│ │ └── bevy_internal v0.12.1 (*)
│ ├── bevy_sprite v0.12.1 (*)
│ ├── bevy_text v0.12.1 (*)
│ └── bevy_ui v0.12.1 (*)
└── wgpu-core v0.17.1
└── wgpu v0.17.2 (*)
```
```
windows v0.46.0
└── cpal v0.15.2
└── rodio v0.17.3
└── bevy_audio v0.12.1
└── bevy_internal v0.12.1
└── bevy v0.12.1
```
```
windows v0.48.0
└── accesskit_windows v0.15.1
└── accesskit_winit v0.15.0
└── bevy_winit v0.12.1
└── bevy_internal v0.12.1
└── bevy v0.12.1
```
```
windows v0.52.0
└── gilrs-core v0.5.10
└── gilrs v0.10.4
└── bevy_gilrs v0.12.1
└── bevy_internal v0.12.1
└── bevy v0.12.1
```

This is a pretty big issue for rust-analyzer users at least (and I assume not too nice for compilation speed either). Why? Well, these crates are absolutely massive, and due to how rust-analyzer works (for the time being, ideally it wouldn't), rust-analyzer currently loads every source file into memory at start up for speed (and unfortunately duplicates this for normalizing file endings). This wastes a ton of memory due to the windows crate being enormous in source code size (a whopping `1.5` - `1.6`gb!), and this is without any other related computed information like early name resolution which could be pretty big for these crates as well!

Now this is not a problem for bevy itself, but certainly for the user experience of people working with the engine in rust-analyzer so I figured I should bring this up.

## Additional information

https://github.com/rust-lang/rust-analyzer/issues/16301

Contributor guide

Open the contributing guide

Research direction

Start with the Cargo dependency tree in the issue and inspect the version constraints for gpu-allocator, cpal, accesskit-winit, and gilrs. Check the linked rust-analyzer issue for the memory impact and determine whether compatible dependency updates can reduce the four windows versions. Done means validating the resulting Bevy dependency tree and confirming the affected integrations still build.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
build-system, developer-experience
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.