Consider breaking bevy_core up

[CAD97]

What problem does this solve or what need does it fill?

bevy_core currently serves a number of different roles:

• type registrations: math / std / ecs / time / misc
• time
• names / labels
• FloatOrd
• Byte conversion
• task pool setup

I do think that it is worth revisiting bevy_core.

What solution would you like?

I think we can probably find a solution that satisfies everyone:

• Byte conversion will be deprecated in favor of bytemuck and crevice once the new renderer gets merged
• bevy_math might actually be able to define its own plugin / take a dependency on bevy_app. this forces bevy_math consumers to also consume bevy_app / bevy_ecs / etc, but maybe thats ok.
• time stuff could be broken out into bevy_time
• FloatOrd could be moved to bevy_utils (although its type registration cannot)
• Type registrations could be moved somewhere else (maybe even the top level bevy_internal crate)
• We could consider doing a task pool setup plugin in bevy_ecs or bevy_internal

In short, we might be able to do away with bevy_core entirely. I'd prefer to start doing this stuff after the new renderer is merged to avoid conflicts / allow us to remove the Bytes stuff entirely. These are all straightforward changes that won't take any real time investment.

What alternative(s) have you considered?

Status quo

Additional context

#2900 (comment); blockquotes are from @cart in linked comment.

[mockersf]

to be looked at after #2535

[colepoirier]

@mockersf saw this just now and your note that you wanted to follow up on this issue after 0.6. So here is your reminder I guess :)

[mockersf]

@colepoirier I didn't want to follow up on that, just that whoever wanted to should wait. Go ahead 😄

[colepoirier]

Ah my bad! I thought I was being helpful lol.

[mockersf]

As this start to be done, I wonder if it would need a more thorough examination before starting to split it. Maybe with a target dependency graph on the changes that could be done?

About the two with started PRs:

• moving time stuff to bevy_time: this mean adding a new very small unit to compile, but reducing the number of crates depending on bevy_core. I'm not sure it would have a positive impact on compile time, but I think it would have a negative one when compiling on a machine without many parallel jobs to compile
• moving FloatOrd to bevy_utils. This is reducing one pile of stuff to increase another. More crates depends on bevy_utils, so it wouldn't be a positive change

To be fair, the compilation impacts should be minimal as the code involved is very small and simple. But I think it makes sense to have "grab-bag" crates, and it makes sense to have a small one (current bevy_core) with the more basic components, and a larger one (bevy_utils) that is needed later in the compilation.

[CAD97]

it makes sense to have a small one (current bevy_core) with the more basic components, and a larger one (bevy_utils) that is needed later in the compilation.

This sentiment is reasonable, but incorrectly informed; in fact, reversed. Every crate which uses bevy_core also directly uses bevy_utils. In fact, bevy_core uses bevy_utils.

All of the below ignores development/test dependencies.

cargo tree -i bevy_core --depth 1

D:\repos\bevyengine\bevy [main ≡]> cargo tree -i bevy_core
bevy_core v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_core)
├── bevy_core_pipeline v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_core_pipeline)
├── bevy_diagnostic v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_diagnostic)
├── bevy_gltf v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_gltf)
├── bevy_internal v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_internal)
├── bevy_pbr v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_pbr)
├── bevy_render v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_render)
├── bevy_sprite v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_sprite)
├── bevy_text v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_text)
└── bevy_ui v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_ui)

cargo tree -i bevy_utils --depth 1

bevy_utils v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_utils)
├── bevy_app v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_app)
├── bevy_asset v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_asset)
├── bevy_audio v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_audio)
├── bevy_core v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_core)
├── bevy_core_pipeline v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_core_pipeline)
├── bevy_diagnostic v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_diagnostic)
├── bevy_ecs v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_ecs)
├── bevy_gilrs v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_gilrs)
├── bevy_gltf v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_gltf)
├── bevy_input v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_input)
├── bevy_internal v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_internal)
├── bevy_log v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_log)
├── bevy_pbr v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_pbr)
├── bevy_reflect v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_reflect)
├── bevy_render v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_render)
├── bevy_scene v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_scene)
├── bevy_sprite v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_sprite)
├── bevy_text v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_text)
├── bevy_transform v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_transform)
├── bevy_ui v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_ui)
├── bevy_window v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_window)
└── bevy_winit v0.6.0 (D:\repos\bevyengine\bevy\crates\bevy_winit)

crate	uses core	uses utils
bevy_app	✗	✓
bevy_asset	✗	✓
bevy_audio	✗	✓
bevy_core	≡	✓
bevy_core_pipeline	✓	✓
bevy_diagnostic	✓	✓
bevy_ecs	✗	✓
bevy_gilrs	✗	✓
bevy_gltf	✓	✓
bevy_input	✗	✓
bevy_internal	✓	✓
bevy_log	✗	✓
bevy_pbr	✓	✓
bevy_reflect	✗	✓
bevy_render	✓	✓
bevy_scene	✗	✓
bevy_sprite	✓	✓
bevy_text	✓	✓
bevy_transform	✗	✓
bevy_ui	✓	✓
bevy_window	✗	✓
bevy_winit	✗	✓

---

The bevy_time split pulls the timer functionality out of bevy_core; bevy_diagnostic no longer uses bevy_core, and uses bevy_time instead.

The FloatOrd move to bevy_utils means that five (5) crates on that list now no longer use bevy_core, and only use bevy_utils: bevy_core_pipeline, bevy_pbr, bevy_sprite, bevy_text, and bevy_ui.

The list of crates using bevy_core after these two PRs is just three (3):

• bevy_gltf: bevy_core::Name.
• bevy_render: bytemuck (cast_slice, Pod).
• bevy_internals: duh.

Imho, bevy_utils should own Name; it already owns Label. The only reason I didn't make a PR for that already is that Name derives bevy_reflect::Reflect, and bevy_reflect uses bevy_utils. This looks to be an invertible dependency; bevy_reflect only uses bevy_utils::{AHasher, Duration, Entry, HashMap, HashSet, Uuid}, all of which are upstream reexports. Or Reflect could be implemented manually in bevy_reflect and keep the dependency edge the current direction. This is a bigger discussion/decision, so I haven't done it yet.

bevy_render can and probably should just use bytemuck directly. Or perhaps the bytemuck dependency and reexport should be lifted to bevy_utils rather than bevy_core.

And after that, all that remains is the CorePlugin, which does two things:

• Creates the default task pools.
  • Imho, this feels like it should live in bevy_task (I have not looked into the practicality of moving this plugin functionality there).
  • Cart suggested it could go in bevy_ecs or just in bevy_internal.
• Registers a bunch of types to the type registry: bevy_math types, primitive types, Range<f32>, String, Option<String>, HashSet<String>, Entity, and Name.
  • NB: FloatOrd isn't even type registered.
  • Imho, the primitive types should be inserted into the type registry by default upon creation in bevy_reflect.
  • The rest of the type registration I don't have a strong opinion on where they should logically go.

And because I installed the cargo plugin to generate these, enjoy some depgraphs (with transitive dependencies deduplicated to make it readable, and focused to the crates we're talking about):

[main ≡]> cargo depgraph --focus bevy_utils bevy_core bevy_time --dedup-transitive-deps

[bevy_nore]> cargo depgraph --focus bevy_utils bevy_core bevy_time --dedup-transitive-deps

(Note: any crate which doesn't transitively use bevy_utils does not show up in this graph, if any exist.)