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?

mintlu8 · 2024-05-28T13:59:33Z

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

tsal · 2024-06-15T12:40:20Z

did bevy::utils::thiserror get removed / moved as part of this effort in 0.14? I can't seem to find the module anymore, but that could be user error (no pun intended).

BD103 · 2024-06-15T13:12:17Z

did bevy::utils::thiserror get removed / moved as part of this effort in 0.14? I can't seem to find the module anymore, but that could be user error (no pun intended).

I believe it did. You can view the draft migration guide here.

mnmaita · 2024-06-15T16:29:25Z

BoxedFuture usage was reduced in #12550 but it still exists. Not sure if there will be a way to completely remove it though (check the convo on that PR for more context).

# 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`.

mnmaita · 2024-08-14T19:08:11Z

Some thoughts on CowArc:

Do we really need this to exist in bevy_utils if it's not shared within bevy (it's only used in bevy_asset AFAICS)?
If it's exported because people are using it on their projects, do we really care to expose this considering they can vendor it or use the cow_arc crate (I understand this is a different implementation, but still)?
Should we be providing this at all, as a game engine?

All my answers to these questions are "No" right now, so I'll appreciate any counter arguments to them.

cart · 2024-08-15T20:19:39Z

My arguments to include it:

This CowArc has unique design constraints. Nothing else in the ecosystem fits the bill currently (to my knowledge).
It exists in some of our public APIs.
It fills a role that may have uses elsewhere in the engine.

From my perspective, that means we need to make this (publicly) available somewhere. In the interest of removing bevy_utils, I could be convinced to move it into bevy_asset. But that feels like it would be a temporary spot for it.

alice-i-cecile · 2024-08-15T20:31:31Z

Could we ship a tiny crate for it? It seems genuinely useful to the ecosystem, and I think that dramatically more people will use it standalone.

mnmaita · 2024-08-16T19:44:34Z

I'm all in for a cart_arc crate honestly. 😆

I could work on any of these items FWIW, moving it temporarily to the asset crate and/or creating a new crate, but I'd need some support for the latter as I won't have the permissions to create a new repo within the org and publish a crate from it.

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

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

Open

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

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

mintlu8 commented May 28, 2024

tsal commented Jun 15, 2024 •

edited

Loading

BD103 commented Jun 15, 2024

mnmaita commented Jun 15, 2024

mnmaita commented Aug 14, 2024

cart commented Aug 15, 2024

alice-i-cecile commented Aug 15, 2024

mnmaita commented Aug 16, 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

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

mintlu8 commented May 28, 2024

tsal commented Jun 15, 2024 • edited Loading

BD103 commented Jun 15, 2024

mnmaita commented Jun 15, 2024

mnmaita commented Aug 14, 2024

cart commented Aug 15, 2024

alice-i-cecile commented Aug 15, 2024

mnmaita commented Aug 16, 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

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

tsal commented Jun 15, 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