Component Guided Optimisation

[mockersf]

rendered: https://github.com/bevyengine/rfcs/blob/component-guided-optimisation/rfcs/84-component-guided-optimisation.md

help improve release builds of Bevy games:

• less CPU and RAM usage
• lower scheduler contention
• shorter compilation time
• smaller binaries
• what else?

[Atlas16A]

My first immediate thought is, how does this mesh with bsn? Components might be used by bsn but the rust side only has the component declaration.
This also effects the editor workflow as youd make a component, not use it in code, go to put it on stuff inside the editor only for the editor to have zero clue what it is cause it got optimized out.

[mockersf]

My first immediate thought is, how does this mesh with bsn? Components might be used by bsn but the rust side only has the component declaration.

It should be possible to identify those components used at runtime with dynamic analysis, and it would be very easy to do it as static analysis: it's pretty much just reading the file! So no issues there, but good to mention

This also effects the editor workflow as youd make a component, not use it in code, go to put it on stuff inside the editor only for the editor to have zero clue what it is cause it got optimized out.

This doesn't affect the editor as it's targeted at final deliverable, so not while you're using the editor

[komadori]

I love it! I've long thought that Bevy needed a much more fine-grained feature set and worried that increasing capabilities for dynamism and introspection in the engine would impair the ability of the compiler to remove dead code. As you point out, the registration of systems is already a big anchor for lots of functionality.

I expect that it might ordinarily be difficult to get a lot more finer-grained features implemented and merged owing to debate over the merits and precise boundaries of each such proposal, if such things are seen as having an overhead. That is the real genius of this RFC, that it envisages a systemic way of componentising Bevy using... components. By establishing a standard practice as proposed, the impact on developers working on or using the full engine should be minimal while ensuring that fine-grained features are pervasive.

I will only note that Component level granularity doesn't solve every problem as there are other confluence points where logically separate features are combined (e.g. the GLTF loader, StandardMaterial, etc). However, I think this would be a fantastic place to start.

[BD103]

Although it may be overkill, you can accomplish the static analysis by creating a rustc driver, just like the Bevy Linter does. rustc drivers give you full access to type information, attributes, the AST / HIR, and some amount of compile-time evaluation, which is super useful! As a downside, however, rustc drivers require constant maintenance to to use a modern nightly toolchain and "stay ahead" of stable Rust, not to mention there's little support from the compiler devs (required unstable features, no internal changelog, no migration guide yet).

A rustc driver will definitely give you the power you need for static analysis, but it's high maintenance and very domain-specific. I'd recommend looking at alternatives first before going down this route! :)

[jdm]

charon might be an alternative that would enable static analysis without requiring constant maintenance.