"Constant Resources" for configuration data that is constant in a release build

[SamPruden]

It's fairly typical for games to have a subset of assets/resources which represent configuration data. These are often only exposed as assets to allow them to be tuned during development, but in a release build they represent constant data. In some cases, it may be a worthwhile optimisation to inline and fold these as constants during compilation. Should Bevy have some concept of a "constant resource" to address this?

An example might be the player controller that I'm currently working on in Unity. It's grown to have more than 20 configurable values, from simple floats to Bezier splines, all of which control the feel of the controller and are exposed for tweaking in the editor. There are a few instances where constant folding even the floats would make a significant difference to performance, and the Bezier splines in particular could be handled much faster if they were inlined as constant polynomial splines with constant numbers of points. I may manually inline these things when I'm confident that I won't need to tweak any further.

As a very rough sketch, I'm imagining that these resources could somehow be const loaded in a release build, and fed into systems in a way that allows the system bodies to inline the resource values if LLVM wants to. In a future Bevy Editor, an editor build might compile these systems to have two paths; a fast path that behaves like release, and a slow path that falls back to a dynamic resource if it has been changed in the editor since the last recompile.

I see a number of things that make this hard. Among them, the types of assets that are likely to benefit from this most (the Bezier splines in my example) don't inline naturally in Rust. In my limited Rust experience, I understand that the unsized types restrictions mean that the natural way to implement something like an editable Bezier spline is with Vec<ControlPoint>, and I'm not sure how one would go about persuading the compiler to inline that as constant data.

Is this something worth considering? Is it feasible?

[alice-i-cecile]

Interesting: I wonder if we could insert a pointer into the ECS to a global constant.

The API for this wouldn't be too terrible, but I worry that it may not actually result in the performance improvements you're looking for.

The general concept doesn't sound like it should be purely restricted to resources: component data would benefit from this too.

[SamPruden]

The API for this wouldn't be too terrible, but I worry that it may not actually result in the performance improvements you're looking for.

This thought grew out of me wishing that Unity could do this, and briefly considering trying to implement it myself with code generation. The ideal version of it would definitely be an improvement in my case, but there may be the issue that the most beneficial things to inline are typically in data structures that the compiler doesn't know how to inline.

Is there some other reason it's unlikely to be beneficial?

The general concept doesn't sound like it should be purely restricted to resources: component data would benefit from this too.

Yeah I briefly thought about doing it for components too, but I wasn't sure what that would look like. Are you imagining that we tell the compiler "Every single instance of FooComponent has value set to 5 and it never changes, so inline it as constant."?

[alice-i-cecile]

Is there some other reason it's unlikely to be beneficial?

I am just generally skeptical of the perf implications of complex optimizations: the compiler is a fickle beast! I think it's promising enough to try out and benchmark though :D

Yeah I briefly thought about doing it for components too, but I wasn't sure what that would look like. Are you imagining that we tell the compiler "Every single instance of FooComponent has value set to 5 and it never changes, so inline it as constant."?

Originally my thought is that we could have data which we cannot hand out a mutable reference to, and is somehow communicated to the compiler about.

As I think about this more, I wonder if we can use associated constants to get the benefits here. Effectively, that's what we want, and then there's no special machinery needed. Ideally these could still be modified using some form of hot reloading for quick experimentation: I wonder if we can adapt the mechanisms in bevy_inspector_egui's hot-reloading of parameter values to handle this.

Obviously changing the value of a constant at run-time is going to be UB, but if we could change whether it's constant or not based on how it's compiled I think that gets us the behavior you need.