Remove or shrink bevy_utils #11478

doonv · 2024-01-22T18:22:39Z

alice-i-cecile · 2024-01-22T18:25:43Z

Yes please: I want this crate eliminated!

alice-i-cecile · 2024-01-22T18:27:53Z

I think we may want to spin up new crates in the Bevy org for some of the stand-alone utilities.

@cart, would that make sense to you? Things like the default function crate would be good to split out, and will change slowly enough that I don't have concerns about moving it out of the monorepo.

That said, I know you're reluctant about increasing crate number, just because it's a popular misguided punching bag for "dependency bloat".

doonv · 2024-01-22T18:42:07Z

I'm curious whats the compile-time performance penalty of switching between compiling different crates vs. the compile-time performance penalty of compiling unused parts of a crate.

hymm · 2024-01-22T18:52:32Z

label is used in bevy_ecs to define ScheduleLabel trait and SystemSet trait. So maybe should be there.

get_short_name is used in bevy_asset in a Debug impl, bevy_ecs for some ambiguity reporting, and bevy_heirarchy for a warning. So I don't think it makes sense in bevy_reflect which is an optional dependency for those crates. Not sure where it should go though.

alice-i-cecile · 2024-01-22T19:27:04Z

get_short_name feels like a general purpose Rust utility, or maybe something that belongs in bevy_reflect for working with types and paths.

Use `TypeIdMap<T>` instead of `HashMap<TypeId, T>` - ~~`TypeIdMap` was in `bevy_ecs`. I've kept it there because of #11478~~ - ~~I haven't swapped `bevy_reflect` over because it doesn't depend on `bevy_ecs`, but I'd also be happy with moving `TypeIdMap` to `bevy_utils` and then adding a dependency to that~~ - ~~this is a slight change in the public API of `DrawFunctionsInternal`, does this need to go in the changelog?~~ ## Changelog - moved `TypeIdMap` to `bevy_utils` - changed `DrawFunctionsInternal::indices` to `TypeIdMap` ## Migration Guide - `TypeIdMap` now lives in `bevy_utils` - `DrawFunctionsInternal::indices` now uses a `TypeIdMap`. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

Use `TypeIdMap<T>` instead of `HashMap<TypeId, T>` - ~~`TypeIdMap` was in `bevy_ecs`. I've kept it there because of bevyengine#11478~~ - ~~I haven't swapped `bevy_reflect` over because it doesn't depend on `bevy_ecs`, but I'd also be happy with moving `TypeIdMap` to `bevy_utils` and then adding a dependency to that~~ - ~~this is a slight change in the public API of `DrawFunctionsInternal`, does this need to go in the changelog?~~ ## Changelog - moved `TypeIdMap` to `bevy_utils` - changed `DrawFunctionsInternal::indices` to `TypeIdMap` ## Migration Guide - `TypeIdMap` now lives in `bevy_utils` - `DrawFunctionsInternal::indices` now uses a `TypeIdMap`. --------- Co-authored-by: Alice Cecile <alice.i.cecile@gmail.com>

# Objective Reduce the size of `bevy_utils` (#11478) ## Solution Move `EntityHash` related types into `bevy_ecs`. This also allows us access to `Entity`, which means we no longer need `EntityHashMap`'s first generic argument. --- ## Changelog - Moved `bevy::utils::{EntityHash, EntityHasher, EntityHashMap, EntityHashSet}` into `bevy::ecs::entity::hash` . - Removed `EntityHashMap`'s first generic argument. It is now hardcoded to always be `Entity`. ## Migration Guide - Uses of `bevy::utils::{EntityHash, EntityHasher, EntityHashMap, EntityHashSet}` now have to be imported from `bevy::ecs::entity::hash`. - Uses of `EntityHashMap` no longer have to specify the first generic parameter. It is now hardcoded to always be `Entity`.

# Objective Reduce the size of `bevy_utils` (bevyengine/bevy#11478) ## Solution Move `EntityHash` related types into `bevy_ecs`. This also allows us access to `Entity`, which means we no longer need `EntityHashMap`'s first generic argument. --- ## Changelog - Moved `bevy::utils::{EntityHash, EntityHasher, EntityHashMap, EntityHashSet}` into `bevy::ecs::entity::hash` . - Removed `EntityHashMap`'s first generic argument. It is now hardcoded to always be `Entity`. ## Migration Guide - Uses of `bevy::utils::{EntityHash, EntityHasher, EntityHashMap, EntityHashSet}` now have to be imported from `bevy::ecs::entity::hash`. - Uses of `EntityHashMap` no longer have to specify the first generic parameter. It is now hardcoded to always be `Entity`.

Kanabenki · 2024-02-29T11:24:13Z

Regarding the tracing utiliities in bevy_utils, I checked whether that could be easily moved to bevy_log, but that creates a deps cycle since it already depends on bevy_app and bevy_ecs because of the LogPlugin. Would it make sense to have a bevy_tracing crate just for re-exporting tracing + the few tracing utilities?

# Objective Make bevy_utils less of a compilation bottleneck. Tackle #11478. ## Solution * Move all of the directly reexported dependencies and move them to where they're actually used. * Remove the UUID utilities that have gone unused since `TypePath` took over for `TypeUuid`. * There was also a extraneous bytemuck dependency on `bevy_core` that has not been used for a long time (since `encase` became the primary way to prepare GPU buffers). * Remove the `all_tuples` macro reexport from bevy_ecs since it's accessible from `bevy_utils`. --- ## Changelog Removed: Many of the reexports from bevy_utils (petgraph, uuid, nonmax, smallvec, and thiserror). Removed: bevy_core's reexports of bytemuck. ## Migration Guide bevy_utils' reexports of petgraph, uuid, nonmax, smallvec, and thiserror have been removed. bevy_core' reexports of bytemuck's types has been removed. Add them as dependencies in your own crate instead.

…e#12313) # Objective Make bevy_utils less of a compilation bottleneck. Tackle bevyengine#11478. ## Solution * Move all of the directly reexported dependencies and move them to where they're actually used. * Remove the UUID utilities that have gone unused since `TypePath` took over for `TypeUuid`. * There was also a extraneous bytemuck dependency on `bevy_core` that has not been used for a long time (since `encase` became the primary way to prepare GPU buffers). * Remove the `all_tuples` macro reexport from bevy_ecs since it's accessible from `bevy_utils`. --- ## Changelog Removed: Many of the reexports from bevy_utils (petgraph, uuid, nonmax, smallvec, and thiserror). Removed: bevy_core's reexports of bytemuck. ## Migration Guide bevy_utils' reexports of petgraph, uuid, nonmax, smallvec, and thiserror have been removed. bevy_core' reexports of bytemuck's types has been removed. Add them as dependencies in your own crate instead.

# Objective - Attempts to solve two items from #11478. ## Solution - Moved `intern` module from `bevy_utils` into `bevy_ecs` crate and updated all relevant imports. - Moved `label` module from `bevy_utils` into `bevy_ecs` crate and updated all relevant imports. --- ## Migration Guide - Replace `bevy_utils::define_label` imports with `bevy_ecs::define_label` imports. - Replace `bevy_utils::label::DynEq` imports with `bevy_ecs::label::DynEq` imports. - Replace `bevy_utils::label::DynHash` imports with `bevy_ecs::label::DynHash` imports. - Replace `bevy_utils::intern::Interned` imports with `bevy_ecs::intern::Interned` imports. - Replace `bevy_utils::intern::Internable` imports with `bevy_ecs::intern::Internable` imports. - Replace `bevy_utils::intern::Interner` imports with `bevy_ecs::intern::Interner` imports. --------- Co-authored-by: James Liu <contact@jamessliu.com>

mnmaita · 2024-04-26T12:57:51Z

label and intern modules were moved into bevy_ecs. You can tick those whenever you can. I might work on some other items on this list later. Thanks!

mnmaita · 2024-05-23T14:10:41Z

FloatOrd can be ticked as it was moved here.

Regarding stuff like CowArc and OnDrop, does it make sense to have these as crates within the bevy repo, or would it make more sense to have them as standalone repositories within the org?

alice-i-cecile · 2024-08-16T23:28:00Z

I'm on board with this, and have @cart's blessing. I'm on vacation this week, but please prompt me to get you set up on August 26, 2024.

MarcGuiselin · 2024-09-06T17:56:07Z

bevy_utils::{HashMap, HashSet} can be replaced with std::collections::{HashMap, HashSet} since hashbrown is now part of the std library. There's no reason to use hashbrown directly unless we care about no-std. (See https://github.com/rust-lang/hashbrown) ~~The default hasher also uses aHash.~~

Should make for a very simple pr (I can open it), and it might reduce final bundle size since we arn't shipping an extra implementation, but are using the same implementation from std most devs already use.

About HashMap, I suggest kill it completely and replace with rustc_hash::FxHashMap.

For a future bevy with a nice modding system, I feel like the protection offered against HashDoS is a good thing... but I'm not entirely sure.

@mintlu8 Are there benchmarks for performance of rustc_hash compared to std::collections?

hymm · 2024-09-06T18:17:00Z

The default hasher for std library seems to be SipHash. https://doc.rust-lang.org/stable/std/collections/struct.HashMap.html

The default hashing algorithm is currently SipHash 1-3, though this is subject to change at any point in the future. While its performance is very competitive for medium sized keys, other hashing algorithms will outperform it for small keys such as integers as well as large keys such as long strings, though those algorithms will typically not protect against attacks such as HashDoS.

MarcGuiselin · 2024-09-06T18:33:29Z

Thanks @hymm, I stand corrected. So we don't want to use std::collections directly, but aliased in order to use aHash. That actually simplifies things.

mintlu8 · 2024-09-08T05:12:56Z

@mintlu8 Are there benchmarks for performance of rustc_hash compared to std::collections?

This is an old benchmark for rustc_hash 1.0. (fxHash)

https://medium.com/@tprodanov/benchmarking-non-cryptographic-hash-functions-in-rust-2e6091077d11

rustc_hash has since released 2.0 and uses a different algorithm. ~~I will update this after I do a benchmark myself.~~

rustc_hash 2.0 uses a modified wyhash and it's a very good overall algorithm compared to the original fxHash, see relevent benchmarks from the same test suite in the article. Also unlike ahash, it's hardware independent, which is a plus.

https://pastebin.com/VTwYEN4L

mintlu8 · 2024-09-08T05:53:02Z

Side note: tracing re-export can probably just be removed since #[instrument] doesn't work if you don't have the actual tracing crate in your project.

SkiFire13 · 2024-09-10T20:35:45Z

bevy_utils::{HashMap, HashSet} can be replaced with std::collections::{HashMap, HashSet} since hashbrown is now part of the std library. There's no reason to use hashbrown directly unless we care about no-std. (See https://github.com/rust-lang/hashbrown) ~~The default hasher also uses aHash.~~

Should make for a very simple pr (I can open it), and it might reduce final bundle size since we arn't shipping an extra implementation, but are using the same implementation from std most devs already use.

Note that hashbrown will still be in bevy's dependency tree due to indexmap (used by petgraph and naga) and gpu-descriptor (used by wgpu), so there likely won't be big benefits.

BenjaminBrienen · 2024-09-21T00:39:41Z

Addressing default:

The module exists to support an aesthetic preference. It can be removed easily (although it is a LOT of simple edits), but this won't happen unless a decision is first be made by leadership to stop preferring "..default()". Until then, we can't fully remove bevy_utils, but we can still minimize it.

# Objective - Goal is to minimize bevy_utils #11478 ## Solution - Move the file short_name wholesale into bevy_reflect ## Testing - Unit tests - CI ## Migration Guide - References to `bevy_utils::ShortName` should instead now be `bevy_reflect::ShortName`. --------- Co-authored-by: François Mockers <francois.mockers@vleue.com>

cart · 2024-09-24T01:27:13Z

Given how sensitive people are to "init ergonomics", I'm still very biased toward keeping and preferring ..default(). Imo "wanting to remove bevy_utils" is not a good enough reason to remove such a feature. We will always have things in that category, and we'll need somewhere to put them.

I don't like putting default() (or really anything) in bevy_internal, as that prevents things inside bevy_internal from depending on them.

bevy_utils exists to solve this exact kind of problem. We can't just pretend it doesn't exist. If there isn't a satisfying solution that is better than something bevy_utils-shaped, we should consider keeping it (in slimmed down form).

teohhanhui · 2024-10-03T02:10:30Z

..default() just feels like unnecessary deviation from idiomatic Rust. Does it really make any meaningful difference when we consider IDE auto-completion? And IMO considering that the typical Bevy app feels extremely verbose, ..default() seems like it'd be the least of our concerns...

But there's rust-lang/rfcs#1995 which might help in the future...

BenjaminBrienen · 2024-10-10T03:14:17Z

..<_>::default() is also possible

bushrat011899 · 2024-12-19T07:05:48Z

Based on a Discord message from Cart, here are some actionable items that seem to be generally agreeable:

`default` and `assert_object_safe`

These should just be a couple of micro-crates.

What should bevy_utils::default's crate be called? just-default?
What should bevy_utils::assert_object_safe's crate be called? assert-dyn-compatible? Likely should be renamed since object safe is supposed to now be referred to as dyn compatible according to some other Bevy documentation.

Once we have names/repos for these two crates, moving to them should be very straightforward, just like disqualified for get_short_name.

`async`/`Future`

These should be moved into bevy_tasks, since that is our fundamental async crate at this point in time. Downstream creates like bevy_render can freely import bevy_tasks without increasing compile times since it's already a dependency of bevy_ecs, which is about as fundamental as it gets in Bevy.

Platform Support

SyncUnsafeCell and SyncCell are unstable APIs that Bevy is providing a first-party implementation of. The hashbrown, FixedHasher, web_time, and other similar items represent platform compatibility items. Additionally, the no_std efforts have brought in critical-section, portable-atomic-util, and spin in a similar capacity. Instead of spreading these dependencies (and the techniques to work with them on the appropriate platform) across Bevy, let's consolidate them into a focussed crate, bevy_platform_support (or similar name) who's only job is to provide consistent APIs for all platforms.

`tracing`/`log`

Things like log_once should be moved into bevy_log, while the re-export should be removed entirely. Importing these crates directly where needed flattens the dependency graph, which helps with compile times.

BenjaminBrienen · 2024-12-19T09:45:21Z

If each of these are turned into its own issue, it might be easier to organize the work and make it clear if one of the tasks has been picked up.

alice-i-cecile · 2024-12-19T19:11:17Z

Yeah, spin up micro-issues please!

mnmaita · 2024-12-19T19:48:32Z

I can take the moving into bevy_tasks one.

cart · 2024-12-19T21:51:35Z

For default() I like something descriptive like short_default. Also a strong proponent of snake_case crate names / we should use that convention in any crates we make.

# Objective Fixes #16104 ## Solution I removed all instances of `:?` and put them back one by one where it caused an error. I removed some bevy_utils helper functions that were only used in 2 places and don't add value. See: #11478 ## Testing CI should catch the mistakes ## Migration Guide `bevy::utils::{dbg,info,warn,error}` were removed. Use `bevy::utils::tracing::{debug,info,warn,error}` instead. --------- Co-authored-by: SpecificProtagonist <vincentjunge@posteo.net>

doonv added C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Jan 22, 2024

alice-i-cecile added C-Code-Quality A section of code that is hard to understand or change A-Utils Utility functions and types and removed C-Feature A new feature, making something new possible S-Needs-Triage This issue needs to be labelled labels Jan 22, 2024

doonv mentioned this issue Jan 23, 2024

Move EntityHash related types into bevy_ecs #11498

Merged

SpecificProtagonist mentioned this issue Feb 3, 2024

Use TypeIdMap whenever possible #11684

Merged

alice-i-cecile mentioned this issue Feb 5, 2024

Deprecate StableHashMap/StableHashSet #11717

Closed

james7132 mentioned this issue Mar 2, 2024

Inconsistent use of tracing and bevy_log #11298

Closed

alice-i-cecile mentioned this issue Mar 2, 2024

Replace bevy_log's tracing reexport with bevy_utils' #12254

Merged

james7132 mentioned this issue Mar 5, 2024

Disentangle bevy_utils/bevy_core's reexported dependencies #12313

Merged

alice-i-cecile mentioned this issue Mar 25, 2024

Move FloatOrd into bevy_math #12712

Closed

stinkytoe mentioned this issue Mar 26, 2024

reexported image crate from bevy_render as bevy::render::util::image #12724

Closed

mnmaita mentioned this issue Mar 29, 2024

Moves intern and label modules into bevy_ecs #12772

Merged

alice-i-cecile mentioned this issue Aug 29, 2024

Remove CowArc from bevy_utils and use the new atomicow crate instead #14975

Closed

MarcGuiselin mentioned this issue Sep 10, 2024

bevy_reflect: Replace HashTable with HashMap #15149

Closed

This was referenced Sep 20, 2024

Move ShortName to bevy_reflect #15339

Closed

move ShortName to bevy_reflect #15340

Merged

Remove bevy_utils::default #15342

Closed

remove bevy_utils::{default, prelude} #15343

Closed

BenjaminBrienen mentioned this issue Oct 29, 2024

Prefer Display over Debug #16112

Merged

BenjaminBrienen mentioned this issue Nov 10, 2024

Remove bevy_utils::default() and prefer <_>::default() #16325

Closed

mockersf mentioned this issue Nov 20, 2024

remove the detailed_trace macro #16450

Open

This was referenced Dec 18, 2024

Reorganise Platform Support Dependencies #16877

Open

Split up bevy_core #16892

Closed

mnmaita mentioned this issue Dec 24, 2024

Move futures.rs, ConditionalSend and BoxedFuture types to bevy_tasks #16951

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Remove or shrink bevy_utils #11478

Remove or shrink bevy_utils #11478

doonv commented Jan 22, 2024 •

edited

Loading

alice-i-cecile commented Jan 22, 2024

alice-i-cecile commented Jan 22, 2024

doonv commented Jan 22, 2024

hymm commented Jan 22, 2024

alice-i-cecile commented Jan 22, 2024

Kanabenki commented Feb 29, 2024 •

edited

Loading

mnmaita commented Apr 26, 2024

mnmaita commented May 23, 2024

alice-i-cecile commented Aug 16, 2024

MarcGuiselin commented Sep 6, 2024 •

edited

Loading

hymm commented Sep 6, 2024

MarcGuiselin commented Sep 6, 2024

mintlu8 commented Sep 8, 2024 •

edited

Loading

mintlu8 commented Sep 8, 2024

SkiFire13 commented Sep 10, 2024

BenjaminBrienen commented Sep 21, 2024 •

edited

Loading

cart commented Sep 24, 2024

teohhanhui commented Oct 3, 2024 •

edited

Loading

BenjaminBrienen commented Oct 10, 2024

bushrat011899 commented Dec 19, 2024 •

edited

Loading

BenjaminBrienen commented Dec 19, 2024

alice-i-cecile commented Dec 19, 2024

mnmaita commented Dec 19, 2024

cart commented Dec 19, 2024 •

edited

Loading

Remove or shrink bevy_utils #11478

Remove or shrink bevy_utils #11478

Comments

doonv commented Jan 22, 2024 • edited Loading

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

What solution would you like?

Long list of what to do with each item in bevy_utils

alice-i-cecile commented Jan 22, 2024

alice-i-cecile commented Jan 22, 2024

doonv commented Jan 22, 2024

hymm commented Jan 22, 2024

alice-i-cecile commented Jan 22, 2024

Kanabenki commented Feb 29, 2024 • edited Loading

mnmaita commented Apr 26, 2024

mnmaita commented May 23, 2024

alice-i-cecile commented Aug 16, 2024

MarcGuiselin commented Sep 6, 2024 • edited Loading

hymm commented Sep 6, 2024

MarcGuiselin commented Sep 6, 2024

mintlu8 commented Sep 8, 2024 • edited Loading

mintlu8 commented Sep 8, 2024

SkiFire13 commented Sep 10, 2024

BenjaminBrienen commented Sep 21, 2024 • edited Loading

cart commented Sep 24, 2024

teohhanhui commented Oct 3, 2024 • edited Loading

BenjaminBrienen commented Oct 10, 2024

bushrat011899 commented Dec 19, 2024 • edited Loading

default and assert_object_safe

async/Future

Platform Support

tracing/log

BenjaminBrienen commented Dec 19, 2024

alice-i-cecile commented Dec 19, 2024

mnmaita commented Dec 19, 2024

cart commented Dec 19, 2024 • edited Loading

doonv commented Jan 22, 2024 •

edited

Loading

Long list of what to do with each item in `bevy_utils`

Kanabenki commented Feb 29, 2024 •

edited

Loading

MarcGuiselin commented Sep 6, 2024 •

edited

Loading

mintlu8 commented Sep 8, 2024 •

edited

Loading

BenjaminBrienen commented Sep 21, 2024 •

edited

Loading

teohhanhui commented Oct 3, 2024 •

edited

Loading

bushrat011899 commented Dec 19, 2024 •

edited

Loading

`default` and `assert_object_safe`

`async`/`Future`

`tracing`/`log`

cart commented Dec 19, 2024 •

edited

Loading