bevy_new_2d

[fierce jewel]

Either inserts the component, or uses a relationship...

[finite depot]

Monitor is not an entity IIRC, so relationship wouldn't work, no?

[fierce jewel]

Monitor is an entity

[finite depot]

oh, nice!

Then relationship is the way to go, yeah 🙂

[fierce jewel]

All right time to try and understand how relationships work in 0.16 since I've not really touched them yet.

[fierce jewel]

@finite depot https://crates.io/crates/bevy_link_window_to_monitor

[finite depot]

Just tested this, and wow, this is quite nice for productivity. Thanks again!

[finite depot]

Thanks for publishing this 😄

Looks really solid, good job!

[fierce jewel]

My pleasure!

I could probably make the documentation a bit better, but it's like...super simple.

You either just...use the Plugin and it automagically manages it or you don't and use the function to get the Monitor directly.

[finite depot]

Life hack: you can include your readme in your docs 🙂

That's nice in docs.rs and allows you to add usage examples to your readme that will be validated by cargo test --doc

[tacit verge]

binary size reduction tips for wasm

[finite depot]

Also this

I'll try all three of these in foxtrot real quick and report back on the result

[mortal breach]

I tested a bunch of settings a while back: https://github.com/rparrett/bevy_wasm_bench

Going to update this to add panic and test with Bevy 0.16. (results there are from Bevy 0.14)

[finite depot]

Oh right, I remember this! Thanks for bringing it up again 🙂

[finite depot]

Update: went from

• 176 Mib uncompressed, 102 MiB compressed to
• 136 MiB uncompressed, 98 MiB uncompressed

[finite depot]

Could you ping us in https://github.com/TheBevyFlock/bevy_new_2d/issues/402 when you're done?

[mortal breach]

Sure. Will start the thing running before I head to work this morning.

[finite depot]

thanks a bunch!

[finite depot]

How's the vibe here regarding CI speedups that involve things like nightly, mold, cranelift, etc?

not for releases, just for the regular CI

[tacit verge]

cargo-nextest is a thing too, idk if it offers any benefits over cargo-test if you're only running a couple of tests though

[tacit verge]

i'm definitely in favor of this for my jam template at least

[finite depot]

I'm adding it right now to avian to test

[finite depot]

On it for Foxtrot as well 🙂

[tacit verge]

let me know how it goes and i'll take a look

btw are you considering running CI using the same nightly toolchain as bevy_lint so the cache can be shared?

because that's a thought that crossed my mind at one point

my template is down to 2.5GB total cache size (between 4 caches) for now 😄

[finite depot]

I did not 👀

[finite depot]

Update: cranelift does not like wasm, and nextest considers "no tests to run" an error 😄

(needs cargo nextest run --no-tests pass or warn)

[tacit verge]

btw, should we be passing --no-fail-fast to cargo test?

[finite depot]

good idea, yes it should!

(Currently trying to figure out how to use mold without clang so that our wasm builds can use mold)

https://github.com/flathub/org.freedesktop.Sdk.Extension.rust-stable/issues/168

Here's what I can offer so far: https://github.com/janhohenheim/foxtrot/pull/379

@tacit verge am I missing anything?

[finite depot]

getting these times on Foxtrot now with no cache

Which is pretty sweet if not for the web build

maybe I should remove it

I overestimated how useful it would be

Then again, we did have compile errors in the 2D template on wasm that went undiscovered for a while

And for jams, it makes sense to make that the only build in the CI

or just do continuous deployment like @tacit verge

Yeah, convinced myself to keep it 😄

I'm having a sliiiight suspicion that nextest is not being cached, though 👀
https://github.com/Jondolf/avian/pull/731 is causing recompilations

[finite depot]

nvm, that was not it. Maybe cache-all-crates: true?

In any case, here's the equivalent for Bevy New 2D: https://github.com/TheBevyFlock/bevy_new_2d/pull/405

[tacit verge]

we may be able to cargo check for web instead of fully building it

[finite depot]

good point

sec

[tacit verge]

let me know when i should review the pr

i'm gonna update our labels to match bevy's labels better and be more useful

we have so many open workflows issues 😭

[finite depot]

now

I wasn't able to put the ugly RUSTFLAGS into env for some reason 🤷‍♂️

In general, I'd be happy if we could merge it like this and let you do a cleanup as a followup, since I believe you know your way around workflows wayyyyy better than me haha

[tacit verge]

yeah i wouldn't mind that

i'll probably workshop it into my own template and come back with another pr

i'll approve it after CI finishes

[finite depot]

thanks 🙂

[finite depot]

hold up

[tacit verge]

ope

[finite depot]

does the config.toml override the RUSTFLAGS or merge them

[tacit verge]

funny timing

it's merged

[finite depot]

hehe

I'll do another PR

[tacit verge]

i'm not sure

[finite depot]

Easy way to test: I'll just add garbage to the env var

oh nvm it does merge

I had an issue where I put --cfg getrandom_backend="wasm_js" in there and non-wasm builds failed

so that var is still read

Let me quickly test the other way around: https://github.com/TheBevyFlock/bevy_new_2d/pull/407

meh

There, should be good now 🙂

@tacit verge I moved all rustflags to the config.toml

Because turns out the env vars have precedence over that file

[tacit verge]

ahh ok

[tacit verge]

LINTER_TOOLCHAIN no longer needed?

i don't see where it's moved to

[finite depot]

We use the GH Action

That env var was IIRC there because we used to install it manually

not bad without cache

Could be better by using cranelift more aggressively, but I'd wait with that until we can confirm that it no longer crashes the test runner

I last checked that about 9 months ago, so there's a decent chance it got better 🙂

hmm you know what? avian has a lot of tests, let me check there real quick

Update: every test with #[should_panic] gets a panic while panicking, failing the test

Ready for merge, in that case

BTW, nextest is indeed wayyyy faster on yarnspinner

that one has many tests, so I notice the difference

[tacit verge]

this doesn't seem to be the case: https://github.com/TheBevyFlock/bevy_new_2d/pull/365/files#diff-944291df2c9c06359d37cc8833d182d705c9e8c3108e7cfe132d61a06e9133dd

i'm not sure what that env variable is for, though. the action does indeed set the correct nightly toolchain when installing bevy_lint, but maybe it does something when bevy_lint runs?

@tranquil breach do you know what the LINTER_TOOLCHAIN env variable is for? the CI seems to work without it and i can't find any references in the bevy CLI repo

[tacit verge]

is this doing the same work as the 24m fresh CI from earlier but in 10m?

[tacit verge]

notably cargo test has to compile your crate to run tests, so technically there are two builds in CI

[tacit verge]

so how did nextest perform on foxtrot and bevy_new_2d? no noticeable improvement? i think as long as it isn't a regression when there are barely any tests, it's still good to include in case a user ends up adding many of their own tests

[tacit verge]

done

[tacit verge]

ok looking at the new CI runs in bevy_new_2d, i can see the results:

• format, docs, bevy lints, and clippy are unaffected
• build for web -> check web goes from ~16m to ~4m
• tests goes from ~12m to ~10m

[tacit verge]

i found that you can install cargo-nextest via taiki-e/install-action, which explicitly supports cargo-nextest but also falls back to cargo-binstall if it can't find the tool you want:

- use: taiki-e/install-action@nextest

i'm not sure what the tradeoffs are for this vs. installing cargo-binstall and then manually running cargo binstall cargo-nextest

it might just be a convenience so you don't need an earlier step to install cargo-binstall first, but i'll look into it a bit

regarding passing --secure to cargo binstall, i couldn't find it in cargo binstall -h. turns out it's enabled by default and the flag is deprecated

[finite depot]

No, this is bevy_new_2d

Don’t remember what our original time was there

[finite depot]

Ah, thx for checking. I got that from nextest's website

[finite depot]

I guess that looks nicer when we have inly one thing to install? Dunno

[finite depot]

nextest takes a few more seconds (< 10) when there are no tests, which I think is alright

[finite depot]

So about 35% better? Nice

Especially considering that the private repos are about twice as slow IIRC

[tacit verge]

that's true, it's possible the other jobs will show a difference in private repos

[tacit verge]

btw, the list of tools supported by taiki-e/install-action doubles as a nice resource for discovering useful cargo tools :p

[tacit verge]

i don't think mold does anything when we don't do any linking (aka produce a binary), so we should only install it for Tests

well maybe cargo check involves linking for procedural macros and build.rs, actually

same thing for cranelift if there's no codegen involved

[tacit verge]

also i'm wondering if we really need to install Bevy's Linux dependencies (apt-get ...) for simple commands like cargo doc

mm nope something is needed at least:

error: failed to run custom build command for `wayland-sys v0.31.6`
[...]
The system library `wayland-client` required by crate `wayland-sys` was not found.

[tacit verge]

if you do a fresh build of a workflow that has a few jobs sharing the same cache, they'll all try to save their artifacts as the new cache when they finish

the first job to finish will succeed in saving its artifacts, the later jobs will log a warning

we could put save-if: false on all but one of the jobs to guarantee which job saves its artifacts and avoid the warnings

[tacit verge]

through trial and error, i've determined that only libxkbcommon-dev can be omitted, but it can be omitted from every job

in my personal template with extra dependencies, here's a fresh build:

i set all the jobs to use the same nightly toolchain so they can all share a cache. Clippy lints finished first so it was the job that saved its cache

and this is the following run using the 550MB cache from Clippy lints:

bevy lints spent 56s compiling bevy_lint from source, so it would've been ~50s

so that confirms we can share a cache between Docs, Clippy lints, and Bevy lints if we set them to the same nightly toolchain

i'll try letting Tests save the cache instead and see how that affects things

[finite depot]

Ah yes you’re right

[finite depot]

Good idea 🙂

[finite depot]

How can your template take longer than foxtrot?

[finite depot]

Ah wait it's about the same

[tacit verge]

still funny

hard to judge transitive deps

[tranquil breach]

You can remove it! That was added back when there wasn’t a dedicated bevy_lint action and the tool chain needed to be hardcoded

[finite depot]

(Reminder for me: create a bug report)

[tacit verge]

update: cargo test uses the test profile while the other 3 jobs use the dev profile, so their build artifacts seem to be inherently incompatible

[finite depot]

Oh, TIL

But makes sense

[finite depot]

Trying something new now: What if we built the tests with dynamic linking and cached the dynamic libraries?

https://github.com/TheBevyFlock/bevy_new_2d/pull/408

Also, we should be able to remove opt-level = 3 from the test config

Just need to override what the Cargo.toml says

hrmm --all-features already implies dynamic linking

But I don't see anything in the swatinem docs that suggests it would cache the dynamic library dir

weird

Just to be sure, I added it to my cached dirs

can't hurt

https://github.com/janhohenheim/foxtrot/pull/386/files

Let's see what this does to foxtrot

(talking about rustc --print target-libdir)

note that I added the .rustup path myself

Hmm, that added a minute to my Foxtrot cold build:

dunno if that was a fluke

[finite depot]

same changes improve speed by one minute on bevy_new_2d

[finite depot]

Cache hit on Foxtrot is a little under 2 minutes now

Where compiling + running the tests is just 22 seconds

[finite depot]

Just realized that my work code is on a private repo, so I'll try the same CI setup there to see the speed
Update: 28m 58s without cache for a project that uses Bevy + Burn as main dependencies

[austere shale]

This will give new meaning to last minute jam fixes 😀

[finite depot]

@tacit verge installing nextest with --force can take quite a while on Windows for some reason (~40 sec), I noticed on avian. Do you know which path we need to add so that the cached nextest is found?
this change here is not enough :/

[finite depot]

In any case, this is ready for merging imo

Just thought of something else: If we disallow all linting from uploading their cache, they could in theory just reuse the cache of the tests job, too 👀

though that would increase the time for downloading the cache, not sure if worth

[finite depot]

pinged Bjorn about this

[normal shale]

I was also thinking that. Especially because bevy build web also executes wasm-bindgen, which shouldn't reveal any further errors, right?

[finite depot]

yeah I didn't even consider that

[finite depot]

It's now doing just check on main FYI 🙂

Unfortunately there's no bevy check, so I had to do cargo check --config 'profile.web.inherits="dev"' --features dev --no-default-features --profile web --target wasm32-unknown-unknown

which is... a bit more verbose

But what I actually want to use is bevy test web

[normal shale]

Yeah fair, I guess for all the config stuff it's useful

[finite depot]

Exactly. It's lovely being able to set features etc. for web directly in the Cargo.toml 🙂

[normal shale]

I guess bevy check is kinda bevy lint, in a way... but also doesn't have web integration

[finite depot]

huh, you're right

bevy lint may benefit from accepting web

Let me open an issue

[tacit verge]

try taiki-e/install-action@nextest instead of installing cargo-binstall followed by binstalling it

idk if it would be any different but may be worth a try

[tacit verge]

i think this is what i tried earlier and didn't work because test vs dev profile being incompatible

maybe there's a way to run tests in the dev profile, or make them compatible, idk 😄

although i assume that may make the tests themselves run slower

[finite depot]

oh right I forgot

[finite depot]

Good idea

[finite depot]

It does solve it... by virtue of reinstalling it

idk, maybe it will get cached on a different path?

Ready for re-review

[tacit verge]

is there a reason we want to cache cargo-nextest in our github cache? we're basically installing it from cache already

[finite depot]

Hmm fair enough

It just seems that whatever binstall was doing to restore it takes long on Windows

But idk if the GH cache would be faster

[tacit verge]

interesting

so was caching the dynamically linked libraries helpful?

[finite depot]

Not sure since I added few optimizations at a time to avian, as one non-cached build takes 35 mins

@tacit verge not sure about option precedence, so I set both to be sure: https://github.com/TheBevyFlock/bevy_new_2d/pull/408/commits/dd7b8217b6b5c16d043b59dc02e3768af6aeb5cf

[tacit verge]

iirc opt-level = 1 should be about as fast as opt-level = 0

[finite depot]

oh okay

let me undo that then

reverted

[tacit verge]

also optimization matters to some extent for tests because the tests actually run

so idk what the optimal balance is, but we can probably expect there not to be that many tests so i can see opt-level = 1 being reasonable

[finite depot]

btw let me know if I should implement anything on our to do list for the next jam

I'm mainly eagerly awaiting the pause menu right now 😄

Also, I'm very much in favor of https://github.com/TheBevyFlock/bevy_new_2d/issues/138 now

But it's also fine to leave it until jam 7

[tacit verge]

just enabling -Zshare-generics=y -Zthreads=0 brought my fresh Tests job from 17m30s to 14m20s

sample size of 1 :p

without mold or cranelift or opt-level changes

cached Tests job went from 1m51s to 1m31s

cache size also went from 900MB to 840MB

also about 25-30s faster for fresh Docs, Clippy lints, and Bevy lints jobs

for cached, maybe a little bit faster? but within noise

i'm gonna try mold next

[tacit verge]

mold was actually within noise or actually slower (probably noise) for every job on a fresh ci run

that's -Z arguments compared to -Z arguments + mold

cache size is unchanged

i'll still try a cached run with mold

[finite depot]

pretty neat 😄

[finite depot]

interesting 👀

[finite depot]

Just FYI, if you ever decided to add a Windows CI runner for some weird reason, that needs to have -Zshare-generics=n when using dynamic linking

[tacit verge]

yeah no difference

surprising, but we probably shouldn't enable mold in that case

will test -Z vs -Z + cranelift next

[tacit verge]

cranelift made no difference or was slower in a fresh run, and cache size is unchanged too

[finite depot]

I'd expect it to shine in partial rebuilds where only the top-level crate needs rebuilding

[tacit verge]

do we want to use nightly toolchain and -Z args for releases too?

is there any reason not to?

other than -Zshare-generics on windows release

actually that seems to only be an issue for windows + dynamic linking, but release builds disable dynamic linking so it should be fine

[finite depot]

Many years ago, it used to sometimes create broken builds

But I have not experienced that since like, pff, 6 years?

But I know some people are iffy about it

I personally would enable it for releases, yes

[finite depot]

yep

But I'd also personally reuse caches for releases too, and I know some people are very against anything but a completely clean build on releases 🤷‍♂️

[tacit verge]

well caches are only really good for frequently run jobs

or i guess if you're sure your dependencies are never going to change :p

[finite depot]

I mean, I have a lockfile for that

And if that didn't change, why not reuse the cache from the last release build?

Not that that's possible right now

[tacit verge]

smh github

somehow -Zshare-generics=y -Zthreads=0 made no difference to my web release compile time

[finite depot]

welp

Did you try LLD for that yet?

[tacit verge]

is it possible bevy CLI doesn't pick up RUSTFLAGS?

[tacit verge]

is that not the default linker?

[finite depot]

nope

[finite depot]

Pretty sure it does, since otherwise it would run into that getrandom thing

[tacit verge]

ic

[tacit verge]

so do i need linker = "lld" in .cargo/config_ci.toml for that?

[finite depot]

exactly, and add it to the dependencies for sudo apt-get install

If it's not on the runner by default

[tacit verge]

i'll leave testing that for the next bevy jam maybe 😅

enough workflow tinkering for me i think

it's in a pretty good place at this point i think. i'll just make a PR to bevy_new_2d to align with the results of tinkering in my personal template

[finite depot]

thanks!

I think I'd still leave mold and cranelift on

Since we have such a simple use-case, a more complex game might very well see improvements

[tacit verge]

hmm my template is already 3000 lines of rust with a decent number of additional 3rd-party crates

[finite depot]

fair enough

[tacit verge]

i'm open to adding them back in the future with evidence that they help ofc

[tacit verge]

done: https://github.com/TheBevyFlock/bevy_new_2d/pull/410

[finite depot]

you sure you want to remove the config_ci.toml? It's pretty nice for tinkering

[tacit verge]

mmm

i think in favor of simplicity yes, since we don't strictly need it after this pr, but i do see the value

[finite depot]

works for me

Why -Cincremental=no?

[tacit verge]

i can remove that, i haven't tested it individually so i'm not sure how much it contributes, but it should reduce the amount of work the compiler has to do

probably marginally at best

[finite depot]

Looks like it's already off by default on our CI: https://github.com/TheBevyFlock/bevy_new_2d/actions/runs/15009718253/job/42176127539#step:10:6

[tacit verge]

context starts here i think: #1271949921708146770 message

[finite depot]

I think we would need it again to check LLD on Wasm builds, right?

Not sure you can set that otherwise

[tacit verge]

basically my logic was: Swatinem/rust-cache doesn't save incremental build artifacts anyways (source), so no point in generating them

but actual impact not measured

[tacit verge]

yeah i think so

no need to test that within bevy_new_2d itself though, if we have evidence that it helps in a different repo that's good enough

[tacit verge]

this link isn't expanding to a specific step for me

[finite depot]

Should be this:

[tacit verge]

ah ok, env variable

[finite depot]

Same for other steps, I believe

so this should already be off

[tacit verge]

found the culprit:

the dtolnay/rust-toolchain action is adding that to env

[finite depot]

aha!

[tacit verge]

i'm curious why it does that, but in that case you're right, we don't need the flag

[finite depot]

Still thinking about this

[tacit verge]

https://github.com/dtolnay/rust-toolchain/issues/26

[finite depot]

I'm just not looking forward to moving all rustflags over to that file again and adding the mv step to all jobs if we decide to use it again

But I also see that right now, there's little benefit

[tacit verge]

oh interesting, Swatinem/rust-cache also sets CARGO_INCREMENTAL=0 😄

[finite depot]

hehe

[tacit verge]

yeah i get that. we can block the pr if you want to test lld first?

[finite depot]

I wonder what a user would prefer? I can see someone finding the extra file annoying, but I can also see them being glad that they can tinker with settings without having to understand the GH workflow

[finite depot]

can do

Queued some builds

• cargo build web with LLD
• cargo build web without LLD
• cargo test with mold + cranelift
• cargo test without mold but with cranelift
• cargo test without mold and without cranelift

(don't expect to get anything other than what you did, but can't hurt to check)

[tacit verge]

i could've done something wrong, the lack of results was surprising to me, so i'm glad to get more data

[finite depot]

Looking at only the build times themselves:

• Web
  • With LLD: 10m 39s and 10m 20s (did two runs accidentally)
  • Without LLD: 13m 28s
• Native
  • With mold + cranelift: 13m 51s
  • Without mold, without cranelift: 14m 38s

Looks like LLD is surprisingly good for Wasm 👀

[tacit verge]

interesting

and this is running in CI, right?

[finite depot]

yep

Want me to do local checks?

[tacit verge]

no need

so that's web dev, right

[finite depot]

yep

[tacit verge]

is there a reason you chose build web to test lld, and test to test mold / cranelift?

[finite depot]

No reason really

But you're right, should have done build for native

[tacit verge]

also is this with -Z flags enabled for all cases?

[finite depot]

yep

[tacit verge]

lld is supposed to be slower than mold in theory right

[finite depot]

that's what I've heard, yeah

I could also try using LLD for native and see what happens

Right now I'm running mold without cranelift

[tacit verge]

ok sounds good

also for context, is this in bevy_new_2d?

[finite depot]

No, all Foxtrot

[tacit verge]

ah ok

[finite depot]

Wish I could enable mold somehow for wasm to compare

Googling has only revealed threads with people saying it must be possible somehow

I've seen one person change symlinks to let mold pretend it's lld

[tacit verge]

maybe wasm is particularly bottlenecked by linking somehow..

[finite depot]

I don't really see how, but then again, I have very little knowledge about any of the wasm build stuff works, so 🤷‍♂️

Mold w/o cranelift: 15m 7s

[tacit verge]

why is mold bad??

ive been gaslit

is the setup-mold action not working maybe?

[finite depot]

good question

this can be dragged????

[tacit verge]

it's like a minigame while you wait for CI to pass

[finite depot]

somehow LLD now broke for all builds, even web

the heck

@tacit verge explain to me

How can this commit here: https://github.com/janhohenheim/foxtrot/commit/22ef3d994c64434274390ff3b2dedf954c8381d3

Break the web build????

I am shook

[tacit verge]

uhh

does reverting it fix the web build?

it could be spurious?

[finite depot]

Yes, I checked

[tacit verge]

or does the web build magically pick up target.x86_64-unknown-linux-gnu by mistake?

because the host OS is linux

[finite depot]

That would be weeeeird

[tacit verge]

it might be some bevy cli related weirdness, assuming you're using bevy cli commands

[finite depot]

it's cargo build

Testing locally, if I enter bogus in my wasm target config as a linker, bevy build web correctly picks up on it

On another note, I managed to get mold working with wasm locally

[tacit verge]

and these are fresh builds i assume, full cache miss

[finite depot]

Oh, that might actually be it

[finite depot]

symlink /usr/bin/ld to /usr/bin/mold

^note that the symlink is from ld, not lld

oh wait nvm that crashes too

so much for "drop-in replacement"

[tacit verge]

yeah i see in the action that it was a partial cache hit so it restored from the fallback cache

hm

actually that makes sense

[finite depot]

that would explain it, yeah

[tacit verge]

you only edited .cargo/config_ci.toml, but Swatinem/rust-cache doesn't include that file in the hash to see if you've changed something important

[finite depot]

I'm getting supremely sleepy over here, so this is all for today I can muster

I guess we found out that mold is not that fast after all in our use-case and that lld is good at wasm?

Not sure how rigorous that testing was

I'm also fine with merging your PR now if you really don't like the config_ci.toml, it's fine

[tacit verge]

did we test lld for native?

or it broke when you tried to test it ig

[finite depot]

that would have been the last test, but my eyes will fall shut if I wait for it 😄

[tacit verge]

yeah for sure

i'll leave the PR open for now because the lld + wasm result was significant

i can work on pause / settings menu stuff anyways :)

[finite depot]

I approved it in the meantime (TIL you can approve drafts)

I'll leave it up to you to include the config.toml or not

[tacit verge]

ok sounds good

[finite depot]

I think -Clinker=lld should also work when set in the RUSTFLAGS env var

Or -Clinker=rust-lld, whatever that means

hold up what

https://github.com/rust-lang/rust/issues/71515

So Wasm should already use LLD by default?????

[tacit verge]

o.O

so replacing lld with lld made it take 3 minutes less

[finite depot]

maybe that's outdated? the post is from 2020

[tacit verge]

@tranquil breach @normal shale any idea what might explain these results?

[tacit verge]

and this, is mold bad actually or does the setup-mold action not work? i'm not sure how to investigate this

[finite depot]

(Note: I might have hecked up and had partial cache hits in these tests)

[normal shale]

For dev builds on Linux, you could also try the wild linker if you haven't already :)

There was also a RustWeek talk about it but unfortunately I missed it :(
I heard that it's quite fast though

[normal shale]

Honestly, no idea :P

Thanks for all this thorough testing though, that will be of great use to everyone!

[finite depot]

TIL about wild
@tacit verge that readme contains some benchmarks that make me think we tested noise

Their differences with LD are in the range of 1 second or below

Which makes a huge difference when going partial rebuilds (e.g. 5 vs 6 seconds on my machine) but are probably totally gobbled up by our clean build times

So the more representative use-case could be to test a cache hit

Same with cranelift

Otherwise, we have all that compilation noise in the background that is completely unaffected by the linker or cranelift

Since I'm a bit tired of benching these, I'm personally gravitating towards trusting the people who already benched non-Bevy use cases and using cranelift + wild + that extra config file.
After some deliberation, I think having a separate file is more user friendly, as that allows you to completely ignore the workflow and stay in Rust land when tuning these knobs

But if you feel strongly about this increasing our complexity for only theoretical gains, I'm fine with merging your PR as-is too

Btw, wild supports binstall, so adding should be trivial 🙂

[finite depot]

Since Foxtrot does not use #[should_panic], I tried activating cranelift for all deps. The clean built time for the tests job went from 16 minutes to 6 minutes 👀

[tacit verge]

well that's pretty significant

why were we disabling cranelift for deps again?

[tacit verge]

hmm the issue is a 1s improvement isn't worth it in CI, where you have the overhead of installing the tool every time instead of on your local machine where you only install it once

plus added complexity meaning more chances for something to break, and more surface area to debug when something goes wrong

[tacit verge]

even if this overhead is like 1s on average, that just cancels out the win

[finite depot]

Fair

[finite depot]

It’s panic = abort, so tests depending on #[should_fail] will break

We could of course just tell people to use llvm if they add such tests

[normal shale]

@finite depot @tacit verge I briefly mentioned your CI compile time experiments to some compiler/AWS people and they were interested in the data

Also apparently better caching is being worked on

[finite depot]

Thx for sharing the data, I hope its useful to them

[normal shale]

Well I didn't share it yet, just mentioned it. But I have their contact information so I can forward it

[finite depot]

Ah alright

It's mostly n = 2 though 😄

[normal shale]

Or if you're interested,I can connect you and maybe they can also share insights back on what we can improve further

[finite depot]

not sure how significant any of that is

[finite depot]

You could shoot them an invite link to this channel if they want

[normal shale]

Fair, but its better than nothing :D

[normal shale]

I think they are on the zulip, not sure if they use Discord. But I can ask

[foggy relic]

You'll have better luck reaching out to them on Zulip 🙂

[normal shale]

I'll do that, and @tacit verge and @finite depot if you're on Zulip I can connect you to them :)

[fierce jewel]

BTW linking this in here because it's relevant: https://discord.com/channels/691052431525675048/1372507436296175686

[tacit verge]

that issue is now fixed :) (#1278871953721262090 message)

[fierce jewel]

I recently saw that.

[finite depot]

Thx for fixing it so quickly!

Good call on skipping the review process for that one 🙂

[tacit verge]

we may actually want to turn off lto (for web builds at least) 👀

https://github.com/TheBevyFlock/bevy_new_2d/issues/402#issuecomment-2884939014

[finite depot]

Why not Fat?

[tacit verge]

this plot is misleading because it includes codegen_units = Default datapoints

if you remove them, the difference between Fat and Off becomes almost negligible, and it costs 2x build time

basically lto only makes a huge difference in the absence of codegen-units = 1

which makes sense: if you already optimized everything as a single unit at compile time, you don't need to optimize everything as a single unit again at link time

[finite depot]

Oooh I see, fair point

[normal shale]

How is codegen units 1 faster build than default?
Because the binary size is smaller so wasm bindgen takes longer?

[tacit verge]

somehow the compile time and wasmopt time are both lower

although the former could be noise

[tacit verge]

otoh, codegen-units only optimizes within your crate while lto should be able to optimize between your crate and your dependencies

more codegen-units probably only helps with build time if your crate is big enough to benefit from parallel compilation within the crate

[tacit verge]

i think the results are also partially skewed by the fact that the benchmarked project isn't representative of a real game :p

it's more like a stress test, so it's performance sensitive but the code surface is small

(it's this crate: https://github.com/rparrett/bevy_wasm_bench/tree/main/bench)

[finite depot]

Maybe I should repeat that test while automatically running through the foxtrot level

[tacit verge]

that would be interesting, maybe limited to a much smaller set of option combinations so it doesn't take forever

would probably also want multiple frame time measurements per build to reduce noise

ultimately i think there is no perfect option combination, as long as we have reasonable evidence-based defaults plus explanations i think we're good (for bevy_new_2d specifically)

[tacit verge]

i'm not able to compile bevy_new_2d on my machine right now: #general message

i ran into that issue while trying to compile my personal template, figured i'd try to compile bevy_new_2d to isolate the problem, but that failed with the same message

[tacit verge]

if someone can try compiling bevy_new_2d with nightly rust 1.89, especially on linux, and let me know if it succeeds or fails, that would help me narrow this down

~$ rustc --version
rustc 1.89.0-nightly (d97326eab 2025-05-15)
~$ cargo --version
cargo 1.89.0-nightly (056f5f4f3 2025-05-09)

[tacit verge]

disabling cranelift, -Zshare-generics=y, -Zthreads=0, mold, and sccache didn't help

[normal shale]

I'll give it a try, just cargo check?

[tacit verge]

i think it's a link-time issue so try cargo build

another user has hit this btw: #general message

[normal shale]

I also had this weird problem on nightly: https://github.com/rust-lang/rust/issues/141085
I wonder if it's related

[normal shale]

It seems to work for me.

rustc 1.89.0-nightly (d97326eab 2025-05-15)
binary: rustc
commit-hash: d97326eabfc3b2c33abcb08d6bc117aefa697cb7
commit-date: 2025-05-15
host: x86_64-unknown-linux-gnu
release: 1.89.0-nightly
LLVM version: 20.1.4

[tacit verge]

interesting

[normal shale]

Ah nevermind, I get the error on cargo run, just not cargo build

[tacit verge]

ahh ok

switching to nightly-2025-04-03 (bevy_lint's pinned version) fixed the issue for me

so that confirms that it's a nightly rust bug

[normal shale]

Now I wonder if that happens on the bug reproduction repo I created for the wasm-bindgen bug, if it's the same features that need to be enabled

Yea I think it might be the same bug, there get "linking with clang failed".
@tacit verge can you check https://github.com/TimJentzsch/bug_wasm-bindgen_env if you get the same error there?

[tacit verge]

i'll take a look

[normal shale]

I was able to narrow it down to the tonemapping_luts and webgl2 features

[tacit verge]

#1373244882151280660 message narrows down the nightly version to >2025-05-14

[tacit verge]

actually i'll get back to this tomorrow, it's late here and i want to write some actual code now that i can compile

[normal shale]

Fair enough!

[tacit verge]

i made the settings menu from pause vs from title screen reuse the same code in my personal template

the trick is to make the title screen's ui actually come from the "main menu", aka a new Menu::Main state

so when you transition from Menu::Main to Menu::Settings and back, it fully replaces the UI but you stay in the same Screen (same for Menu::Pause and Menu::Settings)

can do the same in bevy_new_2d, but without state stacks "go back" is awkward when there are 2 possible previous states

so i think for bevy_new_2d i'll split that into MainSettings and PauseSettings, calling into the same settings() -> impl Bundle, and call it good

although that also means if you want to go deeper with AudioSettings, DisplaySettings, etc., you'll need both a Main and a Pause version of each state 🙃

[finite depot]

I think that’s fine for the moment. Most serious games will have a dedicated submenu for those, but I think this is fine for the scope we are operating on

[normal shale]

Hey @tacit verge @finite depot , sorry to bother you again, I'm trying to summarize the CI performance findings you had to share with the compiler team.
(I'll add a disclaimer that it's a very low sample size and probably not very representative).

What I got so far:

• -Zshare-generics=y -Zthreads=0 => ~20% faster, 7% less size
• Incremental builds are bad for CI (quickly fill up cache)
• LLD is quite fast for Wasm
• cranelift a lot better (~160%) without #[should_panic], but makes no difference otherwise
• mold performs worse or similar to LLD

Is that accurate? Anything else I should add?

[finite depot]

not quite, sec

Cranelift makes the compile time go from 16 min to 6 min when used for the entire dependency tree. However, we cannot use that for tests in general, as cranelift is panic=abort, so should_panic tests fail. So we only used it for the top-level crate, where it does not make a speed difference on CI

Maybe there is a cool set of compilation settings that allows us to keep should_panic tests by compiling some dependency with LLVM and the rest with cranelift?

Mold had no measurable effect on our total compilation times

[normal shale]

Compared to LLD, right?

[finite depot]

Compared to the default native linker, which is not LLD on Linux yet

I think LD?

Using LLD on Wasm made a huge difference, but that seems very sus to me, as I believe Wasm already uses rust-lld by default, so I'm very skeptical of our results there

[finite depot]

This is the reasoning for disabling incremental, but we didn’t compare the performance, since two of our GitHub actions already disable incremental compilations automatically (without us knowing, at first)

The ecosystem in place really really does not want consumers to enable incremental compilation on CI, I expect nearly no one using github workflows has it enabled

[finite depot]

The two Z flags are huuuge improvements. Just note that I was not able to profit from share generics on avian, as we run the tests on multiple OS, including Windows. For extra build speed, we use Bevy's dynamic linking, but that breaks share generics on Windows

I think that are all my comments 🙂

[tacit verge]

what jan said covers it all. making the jobs use compatible toolchain / options so they can share a cache made a big difference for cache size, but that's probably obvious

[finite depot]

https://github.com/janhohenheim/foxtrot/pull/392

not sure if this is an error I made in Foxtrot or relevant to the 2D template

[finite depot]

@tacit verge friendship with tweak_fn has ended; now subsecond is my new best friend

[finite depot]

BTW I just found out why "setting LLD on Wasm" increased our performance on CI.
We mayyyyy currently accidentally ignore the -Z flags for Wasm builds 😅
Haven't verified how it behaves with CI env vars, but .cargo/ci_config.toml stuff would definitely be ignored in bevy run web.
The reason it worked faster in my tests is because I had the getrandom stuff in the config.toml instead of the Cargo.toml.

We could just remove that, but then it results in a very weird footgun to debug for users that happen to pull in getrandom as a transitive dependency

[tacit verge]

i'll take a look at subsecond 😄

[tacit verge]

hmm i'm not following how the config_ci.toml being ignored causes setting LLD to make web builds faster?

something about the getrandom cfg overwriting all the other rustflags so we lose out on the -Z arguments?

[finite depot]

Yep. In my faster run, I happened to move the rustflags from the Bevy CLI-specific config to the generic config.toml, which meant that the other flags were correctly passed in that run

[finite depot]

I'm still figuring out the right combination of settings to make it run as fast as possible and running into weird things like https://github.com/DioxusLabs/dioxus/issues/4149

But right now, I get a fully hotpatched function 0.3s after hitting CTRL-S

[tacit verge]

that sounds pretty promising

i saw in the example they wrote out the same system twice and had one call HotFn::new(system).call(..args) or w/e

would be nice if that was just a proc-macro attribute, it looks like it easily could be

especially if the proc macro was smart and compiled itself out of existence in release builds

[finite depot]

Yep, already added an issue: https://github.com/DioxusLabs/dioxus/issues/4143

[tacit verge]

i just found that 😄

[finite depot]

And right now writing a little crate for just that 🙂

With a bit of luck, this should work later today:

use bevy::prelude::*;
use bevy_simple_subsecond_system::prelude::*;
fn main() {
    dioxus_devtools::connect_subsecond();
    App::new()
        .add_plugins(DefaultPlugins)
        .add_plugins(SimpleSubsecondPlugin::default())
        .add_systems(Startup, setup)
        .add_systems(Update, configure_ui)
        .run();
}

#[derive(Component)]
struct Ui;

fn setup(mut commands: Commands) {
    commands.spawn(Ui);
    commands.spawn(Camera2d);
}

#[hot]
fn configure_ui(ui: Single<Entity, With<Ui>>, mut commands: Commands) {
    commands.entity(*ui).insert(Text::new("Hello, world!"));
}

[tacit verge]

SimpleSubsecondPlugin could call dioxus_devtools::connect_subsecond() internally?

[finite depot]

exactly

#[derive(Debug, Default)]
#[non_exhaustive]
pub struct SimpleSubsecondPlugin;

impl Plugin for SimpleSubsecondPlugin {
    fn build(&self, app: &mut App) {
        dioxus_devtools::connect_subsecond();
    }
}

[tacit verge]

ah, you left that line in fn main in the snippet you sent 😄

[finite depot]

Ah my bad

[tacit verge]

yeah that would be great, i'd definitely try it out during the jam

and before ofc to get it working

[finite depot]

Meh, looks like that one really has to be called by main

[tacit verge]

interesting

[finite depot]

I'll see if I can generate another bug report

oh wait it fails regardless now

🙃

Debugging this is definitely not the most enlightening experience

But when it works, it's great

There we go!

[tacit verge]

amazing

[austere shale]

oooh, that's neat
Is there a way to hook into reloading states to rerun enter systems in some way?

[tacit verge]

like you'd want to trigger a same-state transition by editing some code?

bevy_state doesn't support same-state transitions, you have to leave the state and re-enter it if you want to trigger your OnExit and OnEnter systems for the current state

not due to any technical limitations, i have it implemented in pyri_state

but anyways i'm not sure what code you could edit to trigger a state transition on hot reload, that seems more in the territory of an editor / inspector

maybe you could have a special hot-reloaded exclusive system somewhere that runs once whenever you change it

so you could write world.enter_state(current_state) (pseudocode + assuming same-state transitions are supported), save the file, and it would run that code once

[austere shale]

I know, I've been using a special reset state to get around that.

[austere shale]

Well something like rerunning the setup systems like create UI and whatnot. That would require teardown code anyway, so probably something like the system showed by @finite depot makes much more sense for iteration (and then pulling that into actual systems).

[tacit verge]

maybe the hotpatching setup could support custom "on hotpatch" hooks so you could add one to e.g. re-enter the current state

like it could send an event you could observe

[finite depot]

I'd love to have that, but I haven't found any API in subsecond that tells you it just hotpatched something

Oh nvm

[finite depot]

@tacit verge why did we again reparate a lib.rs and a main.rs? Just for organizational purposes?

Asking because subsecond doesn't like that

[trim zealot]

does subsecond work per-crate or something?

but to answer your question, lib.rs enables integration testing, etc that you can't do with main.rs and is a widespread pattern

[finite depot]

Oooh right, for a tests dir, correct?

[trim zealot]

yah

[finite depot]

It currently only patches things in the bin

[trim zealot]

its also rec'd in the Rust book, so I imagine there's a lot of people doing this: https://doc.rust-lang.org/stable/book/ch12-03-improving-error-handling-and-modularity.html#separation-of-concerns-for-binary-projects

[finite depot]

TIL

[finite depot]

It's planned to be available for deps, but not implemented yet

[trim zealot]

good to know pre-jam at least

[tacit verge]

we can do src/bin/run.rs instead of src/main.rs fwiw, that's what i do in my template because i also have a bin/debug.rs

[finite depot]

oh, by bin I meant "top level crate thingy"

[tacit verge]

ah ok

[finite depot]

I believe once you are referencing code behind a lib.rs, subsecond is gone

[tacit verge]

btw just want to share that i'm experiencing the most cursed bug i've ever seen while trying to set up the settings menu in my personal template

        dbg!((audio_config.music_volume - 0.1).max(0.0)); // This is equal to 0.3
        let x = (audio_config.music_volume - 0.1).max(0.0);
        audio_config.music_volume = x;
        dbg!(audio_config.music_volume); // This is equal to 35.0

[finite depot]

I know why!!

[tacit verge]

🥲

wait really

[finite depot]

There's an atrociously weird line of code in the Volume code that calls abs on negative volumes

that's why in Foxtrot, I first convert it to f32, do math on that, then convert it back to Volume

[tacit verge]

hmm but audio_config.music_volume is an f32, and in the above math it doesn't go negative, it goes from 0.4 to 0.3

[finite depot]

Oh I thought it was a Bevy Volume

nvm then

[tacit verge]

only explanation i can think of is i'm invoking UB somewhere

which i might just be considering i have an unsafe impl of Bundle elsewhere

adding this code right before the snippet i posted "fixed" the bug:

        let x: f32 = 0.4;
        dbg!(x, (x - 0.1).max(0.0));
        let y: f32 = (x - 0.1).max(0.0);
        dbg!(y);

maybe cranelift is breaking something

well it's not cranelift

[finite depot]

Stack corruption?

[tacit verge]

possibly, but how is this happening in rust 😭

i removed the unsafe code and it didn't fix it either

AUDIO WARNING!

this is after a full clean compile with my entire .cargo/config.toml commented out and unsafe code removed

my best guess for now is unsafe code in a dependency (probably bevy) that is not properly vetted for safety

[finite depot]

I've had it happen before through deps

Little one can do except find out which dep API is causing weirdness by bisecting your history

[finite depot]

btw, this looks supremely neat 😄

[finite depot]

cargo test --doc also doesn't work without a lib.rs

[tacit verge]

....

i found the "35.0"

i changed the width to Vw(32.0), and the volume bugged to 32.0 instead of 35.0

[finite depot]

phahahaha

wow

amazing 😄

[tacit verge]

i suppose that's consistent with stack corruption?

what's crazy is how consistent this is, i tried compiling with stable channel and a different nightly version and saw the same behavior

actually no i figured something else out

this is the full snippet:

#[tweak_fn]
fn master_volume() -> impl Bundle {
    fn master_volume_down(_: Trigger<Pointer<Click>>, mut audio_config: ConfigMut<AudioConfig>) {
        let audio_config = r!(audio_config.get_mut());
        audio_config.master_volume = (audio_config.master_volume - 0.1).max(0.0);
    }

    fn master_volume_up(_: Trigger<Pointer<Click>>, mut audio_config: ConfigMut<AudioConfig>) {
        let audio_config = r!(audio_config.get_mut());
        audio_config.master_volume = (audio_config.master_volume + 0.1).min(1.0);
    }

    (
        Name::new("MasterVolume"),
        Node {
            width: Vw(35.0),
            justify_items: JustifyItems::Stretch,
            ..Node::ROW
        },
        children![
            widget::small_button("<", master_volume_down),
            widget::stretch(children![(widget::label("50%"), IsMasterVolumeLabel)]),
            widget::small_button(">", master_volume_up),
        ],
    )
}

the bug started happening when i moved the observer functions into the containing function

removing #[tweak_fn] from the containing function fixes it

so somehow the macro is broken (maybe it doesn't expect inner functions?) in a really weird way

luckily i can replace my usage of #[tweak_fn] with the upcoming hotpatching which is surely not also cursed

thanks for support :)

[tacit verge]

hmmm setting up a window resolution selector is tricky even with bevy_link_window_to_monitor

i can get a window's current monitor now, but i can't get a window's current video mode...

i'm feeling like it's very awkward that window.mode is basically set up as an API for setting the window mode instead of reading it

it's more like window.next_mode_intent right now

i mean, i can get the window's resolution, but not its video mode

at least i can see if the window is in Windowed, BorderlessFullscreen, or Fullscreen, but that's the extent of what you get

also it's possible "video mode" is meaningless if the window is in Windowed mode? i don't have the windowing knowledge here

i'm gonna shelf this for now

[tacit verge]

i'm going to try hotpatching next. @finite depot is v0.1.2 of this crate what i should try? or should i wait for something in the works? https://github.com/TheBevyFlock/bevy_simple_subsecond_system/

(technically this is unrelated to this thread but w/e)

[finite depot]

Give me a few mins

[finite depot]

You can use it now, I'm just adding a feature for automatically rerunning your systems on hot patches

so that Startup systems can just rerun

[finite depot]

Done 👍

[tacit verge]

@finite depot the #[hot] macro doesn't like argument-position impl Trait?

it might just be rust-analyzer being weird one sec

[tacit verge]

this was a great resource: https://www.gameuidatabase.com/index.php?set=1&sort=1&vid=1&plat=1&tag=20&scrn=29

[finite depot]

Oh; I may have to fix that

[tranquil breach]

Hi! It may be another day or two before the CLI gets released, we got held up with some branding issues over in #1278871953721262090

We’re working on it, though, and we’re trying our best to give you all some time to upgrade before the jam :)

[tacit verge]

no rush :)

[tacit verge]

we might consider merging lib.rs and main.rs to remove one hurdle for users who want to experiment with bevy_new_2d + hotpatching for this jam

[finite depot]

Yeah I think I'm in favor

Maybe even a little section in the README pointing to it

[tacit verge]

i have one of those in pyri_new_jam already

[finite depot]

And explaining that you need to disable dynamic linking

[finite depot]

yeah that would be nice

[tacit verge]

in the "run your game" section of the readme

[finite depot]

Just add the disclaimer about disabling dynamic linking as well

Since that is a bit burried inside the "Limitations" section

[tacit verge]

is that not in bevy_simple_subsecond_system? or you think it should be repeated

ok

[finite depot]

Repeated

[tacit verge]

will whip up pr

[finite depot]

thanks!

[tacit verge]

can i do "make sure to read the [known limitations] section!" with a link instead?

[finite depot]

I would mention it explicitly still.
The other limitations are fairly specific, while that one is the one that is guaranteed to not work out of the box unless you disable it in the template

[tacit verge]

also, should i keep the #[cfg_attr] in the recommended annotation

but in this case feature = "dev" i guess

[finite depot]

I think so, yeah

[tacit verge]

even though that means it'll be enabled for web dev builds which doesn't work

[finite depot]

We don't have native_dev on the template?

Huh

[tacit verge]

we don't

one sec

[finite depot]

Wanna add it?

[tacit verge]

no we do

but it's called dev_native

[finite depot]

nice

[tacit verge]

for enabling file watcher atm

is --profile dev really necessary for dx serve? does it not default to that profile?

for bevy_new_2d at least i think --features dev_native isn't necessary because we have that as a default feature

[finite depot]

where do you get that from?

[tacit verge]

hmmm

ah i'm just being silly i think

i probably got it from bevy run --verbose and never questioned it

btw i'm liking the affordance from adding an ellipsis here

i might go through and add that to all our details sections if you agree

[finite depot]

oh yeah it's neat 😄

I like it. Good idea!

[tacit verge]

https://github.com/TheBevyFlock/bevy_new_2d/pull/418

[finite depot]

I'll check in a few mins, max an hour 🙂

[tacit verge]

can you only run doctests in a library repo..?

hm yeah ok https://github.com/rust-lang/rust/issues/50784

[finite depot]

yep

[finite depot]

there's a hack: https://github.com/rust-lang/rust/issues/50784#issuecomment-389515326

[tacit verge]

there seems to be noticeable delay when playing UI sound effects on web

i noticed it in my own template and then found the same issue in bevy_new_2d

if you quickly flick your cursor over and past a button and pay attention, it feels like ~200ms delay

idk if i had this issue when i was using bevy_kira_audio, i migrated to bevy_audio recently

i think my previous jam submission using bevy_kira_audio also has some delay, but it feels like less (which could be due to the sound effect being different)

[tacit verge]

ok wait i like this better

it looks good when expanded

the underline makes it feel like a clickable link while also making it stand out as a mini header for its expanded contents

hmm i can't seem to get github to render the underline though. <u> tag didn't work, <summary style="text-decoration: underline"> didn't work

nvm i got it, needed the <ins> tag

[finite depot]

Can confirm. I really need to check out bevy_seedling at some point

[finite depot]

TIL

[finite depot]

@tacit verge I see you didn't feel like including that hack 😛

Reviewed

[finite depot]

@tacit verge I left a little note on the PR

Looks good otherwise

[tacit verge]

we could bring bevy_new_minimal up to a "checkpoint" / snapshot of bevy_new_2d's metadata and workflows

instead of keeping them constantly in sync

especially since i imagine not everyone will use -t 2d with bevy new

that can at least wait for the 2 draft prs touching metadata

[finite depot]

agreed

Having at least something, even if not fully up-to-date, is probably better than nothing

[tacit verge]

this was a pain to get working

interaction disabling the buttons at the edges

the hard part is re-enabling the left button when you click the right button for example

[finite depot]

Could you use a relationship between the right and left buttons?

[tacit verge]

hmm maybe

this is what i'm doing currently

i'm traversing the selector's entity hierarchy to get the relevant entities

because i didn't want to make 3 different marker components for each volume selector

the correct solution is probably 3 relationships from the main selector entity to the three parts, left button, label, and right button

that's still so awful though

[finite depot]

Oof I see

[tacit verge]

something something reactivity (i'm not a ui dev but i think that's what this needs)

[finite depot]

True Bevy devs say "Let’s wait until BSN"

[tacit verge]

i moved a couple issues to Bevy Jam 7 milestone that i don't see myself being motivated to work on before jam 6

the remaining 3 issues should be completable imo

cargo-binstall for bevy_cli has a draft pr, i'm planning on adding a pause menu (tomorrow i guess), and explaining the profile/features setup in the design doc is just some writing

[finite depot]

Thank you so much for doing those tasks 🙂

I'm suuuper excited for the pause menu implementation 😄

[tacit verge]

haha, accidentally pressing escape in foxtrot must be annoying

with the load time

[finite depot]

yeah it's really bad on Wasm

[tranquil breach]

In case y'all haven't seen it yet, the CLI has finally been released :)

[tacit verge]

it's binstall time

[tacit verge]

i love how bevy_state makes it hard to say something like "upon exiting any screen, close the current menu" :p

yes i am working on the pause menu for bevy_new_2d rn

[tacit verge]

i'll just have to make this explicit per screen

[finite depot]

What, you don't like adding a new ScreenScoped<T> for every single screen?

[tacit verge]

also there may be menu-related 1-frame delays

because i can't do Screen.before(Menu) (pseudocode) in bevy_state

[finite depot]

BTW were you now able to use #[hot] everywhere?

I've so far only added it to functions that I wanted to actually touch, but I'm also considering putting it literally everywhere

[tacit verge]

yes but not the function that returned a system (it compiled and the outer function gets hot patched, but the internal system does not because an instance of it was already returned to the app.add_systems call before the hot patch)

[finite depot]

Oh right I forgot you mentioned that

I could have an extension on ScheduleLabel or however that thingy is called that could do .hot_patched()

app.add_systems(
  Update,
  wait_for(23).hot_patched()
)

I believe the upstreamed version in Francois PR woudln't even need anything like that and just work out of the box

[tacit verge]

yeah if i can just enable a feature on bevy in Cargo.toml it's golden

with an optional macro to tack on some hotpatch-related configuration, that does nothing if the feature is disabled

[finite depot]

Exactly what I was thinking, agreed

[tacit verge]

pause menu working, no bg overlay currently and no actual pausing

[finite depot]

I like how the duckie is looking at the menu options

[tacit verge]

he's pond ering his options

i think i'll make this two prs

[finite depot]

Hehehhe

[tacit verge]

first one adding pause menu, second one adding gameplay pausing

[tacit verge]

i'm gonna leave the translucent pause overlay to a separate pr too :)

i got Esc working for menu navigation (it's all hard-coded 😄)

https://github.com/TheBevyFlock/bevy_new_2d/pull/419

ah i should probably add a header saying "paused" lol forgot (EDIT: added)

[finite depot]

I'll check it out tomorrow 🙂

One thing I'm worried about is that right now, quite a few people may be experimenting with the CLI and the template due to the jam

Which would lead people to use the template in a half-done state if we merge it now

Should we maybe merge all pausing PRs into a separate branch first?

So that we can review parts A, B, C individually while merging them into pause-feature and then merge that branch into main once its done without a new review

(beyond a sanity check of course)

[tacit verge]

hmm idk how to do that, but sure

just create a branch on bevy_new_2d and point the current PR to that branch instead of main?

[tacit verge]

done, the pr targets bevy_new_2d:pause now

[tacit verge]

@finite depot bevy_seedling seems to still be on bevy 0.15?

[finite depot]

ah too bad

[tacit verge]

@finite depot would appreciate review on https://github.com/TheBevyFlock/bevy_new_2d/pull/386 whenever you have time, i've tested that it works in pyri_new_jam :)

[finite depot]

approved 🙂

[tacit verge]

awesome thanks

[trim zealot]

there's a 0.16 branch. I actually just asked them if there was going to be a release for the jam

[tacit verge]

oh will bevy_seedling help with the audio delay? hmm

[finite depot]

should on native, won't yet on Wasm

[tacit verge]

oh 😔

[finite depot]

Author says they want to change audio handling to use JS in the background eventually though

[tacit verge]

i'll probably still use it in pyri new jam for the native improvement though

for the 2 people that download native builds

maybe no point recommending it then? or what's the current value add

at least not before the jam

[finite depot]

cool new spatial API, I believe

but I haven't tried it out yet

so my word is worth veeery little in this regard

[tacit verge]

i also wonder how it compares to bevy_kira_audio, which seems to have some spatial audio support as well

idk

@unkempt drift :)

[tacit verge]

i experimented with bevy_seedling in my template

i'm not seeing any noticeable audio delay in my native build (idk if i had any with bevy_audio though)

audio buses are convenient for changing the volume of an entire category of sounds (already-playing and future)

it takes a little bit of setup to use them, but it's about the same as the setup for the marker components we're already doing anyways

and then bevy_seedling also provides pitch randomization (behind a feature flag) and other audio effects, which i still need to experiment with

and you can apply the effects to individual sounds, or an entire audio bus

API is pretty close to bevy_audio

i think it's reasonable to suggest it for the audio effects / spatial audio

[austere shale]

I'd say pitch randomization would be worth the price of admission alone. That being said, I don't see a feature for that 😅

[tacit verge]

should be rand

oh wait hm

ah there it is, it's in the bevy-0.16 branch 😄

https://github.com/CorvusPrudens/bevy_seedling/blob/952f3ddc2d765d3c82e89b66029d8cb27f90e597/Cargo.toml#L19

[austere shale]

I just looked at the readme of the 0.16 branch at the feature list. My bad 😇

[tacit verge]

what's the fix for this again? i have --cfg getrandom_backend="wasm_js" in my env.RUSTFLAGS...

The "wasm_js" backend requires the `wasm_js` feature for `getrandom`

do i need to enable that feature too? i added bevy_seedling as a dep which has an optional dependency on rand = 0.9, but my cargo tree -i rand doesn't reveal a duplicate version

so i'm confused why i've started hitting this now

i do see two getrandom deps in my tree

[tacit verge]

i fixed it by adding this to my Cargo.toml:

[dependencies]
getrandom = { version = "0.3", default-features = false, features = ["wasm_js"], optional = true }

[features]
web = ["dep:getrandom"]

i still don't know what triggered this

aaaa so bevy CLI also compiles wasm-bindgen-cli from source if you don't already have it, during the bevy build web command

and having --cfg getrandom_backend="wasm_js" in your RUSTFLAGS when that second compilation happens also triggers the error, but you can't fix it in the same way because you can't change wasm-bindgen-cli's Cargo.toml

we should be binstalling the thing anyways so i think i'll add the missing pre-binstall and call it good 🤪

i think i should bring this workaround to bevy_new_2d before the jam so users don't hit this when they add xyz dependency

also i think i'll look into the RUSTFLAGS overwriting issue. pretty sure when we tested mold etc. in CI we weren't actually testing anything because env.RUSTFLAGS was overwriting config_ci.toml

i don't feel like spending a ton of time on workflows though.. so i'm only going to compare nothing enabled to everything enabled (via env.RUSTFLAGS to make sure it's not being overwritten)

[tacit verge]

actually this doesn't normally happen. it happened in relation to this warning:

warning: failed to run wasm-bindgen, trying to find automatic fix...

idk what caused this warning though :)

ah ok i figured it out. it happens on a clean build. on a cached build, we restore the wasm-bindgen binary as well so no need to reinstall

well bevy_seedling seems to fix the audio latency issue on web

but now it's trying to fastforward the beginning of my BGM in a very jarring way

getting super choppy audio now oof

while i'm just in the settings menu of my template

okay i think sadly now is not the time to recommend bevy_seedling, unless there's a fix i'm not aware of

[tacit verge]

ngl it's crazy to me that web release + wasm-bindgen + wasm-opt is 4 minutes faster than.. running tests with no optimizations or features

both uncached

what am i missing?

[tacit verge]

hmm github has somewhat recently started offering linux arm64 runners that are supposedly much faster, but only for public repositories 👀

also ive realized we're compiling dependencies with opt-level = 3 for dev / test builds in CI because of our Cargo.toml...

[tacit verge]

i added a custom [profile.ci] optimized specifically for build time and it shaved 2m off of clean Docs, Clippy lints, and Bevy lints jobs

the Tests job failed with profile ci not found (known profiles: default, default-miri), maybe a next-test issue? 🙃

okay.. cargo-nextest has its own concept of "profile" and doesn't support setting a different cargo profile, cool cool

gotta say goodbye then

oh here's another neat thing, now that the Tests job is using the same profile ci as the other jobs.. it can use the same cache! (i just have to re-enable --all-features)

[finite depot]

Meh

[finite depot]

So I could get the tests down to 4 min on Foxtrot 👀

(Cold)

[tacit verge]

yup, and maybe lower if some other stuff pans out

[finite depot]

Did you do cranelift for all deps yet?

The speedup is craaaazy

[tacit verge]

not yet

i'm gonna try cranelift and mold etc. again once i'm done with this

maybe wild

to see if the RUSTFLAGS overwriting was the issue

[finite depot]

Makes sense that we didn’t see any speedups with mold tho

Should be in the order of single seconds faster

[tacit verge]

yeah makes sense

[finite depot]

Oh right, I changed that in the version with a config.toml IIRC

(Maybe just for foxtrot idk)

[finite depot]

Consider me interested 👀

[finite depot]

Cranelift 😄

[finite depot]

Huh I thought it worked the same as bevy_audio in web

[tacit verge]

cold run with --profile dev and --profile test

[finite depot]

Did you tell Corvus?

[tacit verge]

cold run with --profile ci

[finite depot]

Woah

That’s crazy 👀

I want

[tacit verge]

hehe

[finite depot]

Did you read the related drama? 😄

[tacit verge]

saved to one cache but cache size is 990 MB now for some reason

[tacit verge]

skimmed only

[tacit verge]

i haven't yet

[tacit verge]

ok wait no this makes sense. opt-level = 0 wouldn't even include optimizations to reduce file size

honestly.. --profile ci could set opt-level = "s"

[finite depot]

This one dev is like

No, I have to take a stance against cargos shitty rustflag handling, this will stay shitty until cargo fixes this on their end, it’s time send a signal!!

[finite depot]

Our resident rat sent 2 PRs already to fix it

With about similar results

[tacit verge]

ok somehow cache sharing did not end up as planned

Tests job was happy and took 40s, all the other jobs took 2m

even though they're all using --profile ci and --all-features and the same toolchain

[finite depot]

Oh hey you inverted the problem!

[tacit verge]

haha

[finite depot]

Oh hey, didn’t you also notice that a while ago?

[tacit verge]

yeah, it looks like they're working on improving the status quo upstream recently :)

design work

opt-level = "z" experiment

and somehow the cache size isn't even significantly reduced

it may be that it mostly reduces the size of the final binary, which we aren't caching anyways

but then what is it spending so much time doing while compiling dependencies smh 😩

make it make sense

second time i've seen this happen

another theory: do we really need to install build dependencies on a full cache hit?

the build dependencies are required to build certain cargo deps, but they're already built and restored from cache

Tests job still needs them, the other ones don't!

this saves ~5-10s on cache hit for all jobs except Tests

[finite depot]

This is what I had with nextest!

[unkempt drift]

Hm, what do you mean by this?

I wouldn’t expect any significant performance regression, unless it’s maybe at opt-level = 0.

[tacit verge]

the first ~10s of the music played through quickly before it settled in to playing normally, and it sounded weird

[tacit verge]

i'm using opt-level = 3. i don't know if the issues i encountered were related to fps

[unkempt drift]

Hm, it sounds like the audio time is trying to “catch up,” and likely is related to FPS due to the current main-thread backend. (Although I’d maybe still expect that to happen with rodio.)

I’ll see if I can repro this with the two later.

[tacit verge]

it may be startup fps issues, but that's surprising to me because i don't spawn the SamplePlayer for the music until entering the title screen and everything should already be loaded etc. at that point so fps should be fine

[tacit verge]

if it helps, i experienced the issue in my template on this commit: https://github.com/benfrankel/pyri_new_jam/commit/740003ddb76c3b772c92f08a2bd166a3bad1a80d

[tacit verge]

yeah this keeps happening.. i think i'll add --force but that's so odd

it might be some type of interaction between cargo-binstall and Swatinem/rust-cache. it sees some evidence that bevy_cli is installed so it skips installing it, but maybe only the evidence was cached but not the actual binary

because it should be cached, other binaries are restored from cached

ok i just hit this issue for wasm-bindgen-cli! binstall skips it because it's "already installed", but then bevy_cli sees that it's not installed so it has to install it from source, which hits the wasm_js error

i wonder if we should force a cold run unless the cache is a full match to avoid cache size ballooning over time

pro: users don't have to know to / worry about clearing cache every once in a while to reduce cache size and ci time (downloading a large cache takes longer)
con: the overall ci usage will probably still be higher due to the occasional cold runs overshadowing the 1-3s gains from downloading a smaller cache in cache hits, especially if user changes Cargo.toml often

another option: 10% chance to ignore a partial cache hit for stochastic cache resetting

it could also be considered a correctness / memory leak type of issue

[tacit verge]

my hypothesis seems to be correct! i found this issue: https://github.com/Swatinem/rust-cache/issues/237

which is actually a dupe of this issue: https://github.com/Swatinem/rust-cache/issues/204

[tacit verge]

and there's an issue for this already with the same reasoning: https://github.com/Swatinem/rust-cache/issues/177

[tacit verge]

installing build dependencies with apt-get took 1m40s on the arm64 runner 💀

up from 10s on ubuntu-latest

same story on both ubuntu-24.04-arm and ubuntu-22.04-arm so i guess that's a dead end

[tacit verge]

hmmmmmmm cold run of Tests job with mold enabled through env.RUSTFLAGS took 3m16 on the actual compilation step

cold run without mold took 4m18

sample size of 1 ofc but i mean..

far cry from the old 17m lmao how far we've come

hm ok there's another variable involved, i switched from --all-features to no features between those two so it's not a fair comparison. but i've never seen Tests run that fast

ok the other jobs didn't benefit from mold at all on a cold run. going to try Tests again with no cache, no mold, and no features

[tacit verge]

3m14 seconds, so that seems to confirm the differentiating factor was the features, not mold

in that case i'm not seeing any benefits to mold in CI again, so no point even looking at wild imo due to amdahl's law. cranelift next

2m58s with cranelift enabled

not sure if that's just noise, and not sure if i have it set up properly

2m55s on another run with cranelift + mold

that's sample size of 2 now without cranelift vs with, so the 15-25s speedup seems real

ok notably installing bevy_lint went from 30s to 17s with cranelift and mold enabled lol

only issue is due to the way the action is set up that currently means installing the rust toolchain twice so the savings are lost. will have to see if i can work around that

[tacit verge]

3m06 on another run

[tacit verge]

and a 3m02s with cranelift but no mold

[tacit verge]

another idea: saving the cache takes 10-15s, so it's probably not a good idea to have the job that's already the bottleneck (Bevy lints) do that

ok final results, cold run:

cached run:

Bevy lints is the bottleneck for cached runs now by a wide margin. not only does it take 30-35s to compile bevy_lint, it also takes like 15s longer just to run the lints

here's the issue on bevy cli repo: https://github.com/TheBevyFlock/bevy_cli/issues/461

i'll bring the improvements over to bevy_new_2d soon

[tacit verge]

https://github.com/TheBevyFlock/bevy_new_2d/pull/421

[finite depot]

For only the top crate or all deps?

[finite depot]

Yeah makes sense. The speedup is in single seconds, the install time is in single seconds.

[finite depot]

How far we’ve come from 15+ min indeed, haha

[finite depot]

Can we just cache /usr/bin?

[tacit verge]

should be all deps..

it's enabled with -Zcodegen-backend=cranelift

[tacit verge]

the other stuff wasn't faster either on the arm64 runner unfortunately

idk what the deal is there but i gave up after that

[finite depot]

https://github.com/rust-lang/rust/issues/127979

@tacit verge looks like the rust folks repaired something we ran into in the past

Do you remember what the issue was? I think it was doing a lto = thin + dynamic linking + release mode on Windows?

@tacit verge I finally did the review on the pause menu, sorry for taking a while 🙂

For the follow-ups, I'll try to get them done ASAP so that Chris can do the video

Let me know if I can help somehow other than reviewing

[tacit verge]

ah i forgot to push the commit that removes -Zshare-generics=y before merging, since it's supposedly enabled by default for lower opt-levels

oh well nbd

going to bed now, gameplay pausing tomorrow

[finite depot]

good night 🙂

[normal shale]

In a talk on RustWeek it was said that opt level z is pretty useless right now and maybe should even be removed 🤷‍♂️

[tacit verge]

@finite depot my pr broke the release workflow due to #1278871953721262090 message

i could fix this by adding a web = ["dep:getrandom"] feature and enabling that instead of "dep:getrandom" directly

unless you have a better idea

nvm, fix found! just remove dep:

hm just thought about potential like 2s saving from cargo binstall crate1 crate2 crate3 ...

so the downloads can happen in parallel

[finite depot]

Oh, didn’t know it was parallel when used like that

[tacit verge]

in release workflow we binstall bevy_cli, wasm-opt, and wasm-bindgen-cli for web release, or only bevy_cli for other platforms

[tacit verge]

well i'm only assuming

$ cargo binstall a b c
 INFO resolve: Resolving package: 'a'
 INFO resolve: Resolving package: 'b'
 INFO resolve: Resolving package: 'c'
ERROR Fatal error:
  × For crate a: no binaries specified nor inferred
  ╰─▶ no binaries specified nor inferred

based on this

anyways web release is already faster than the other platforms, no need to micro-optimize it

[finite depot]

Why is getrandom an optional dep?

Oh wait

Yeah I see

Bit confused about why we need the getrandom feature

On my machine, it was always enough to set the rustflag

[tacit verge]

i think you may not have actually hit the bug?

when i pulled in bevy_seedling i started hitting the bug despite using the previous workaround

this setup is what ended up fixing it for me

you get a compilation error if the rustflag is set without the feature enabled

[finite depot]

Could we also just specify the dependency unconditionally for the wasm target?

https://stackoverflow.com/a/51821632

[tacit verge]

that might work

[finite depot]

That has never happened to me I is there an open issue for getrandom?

Because IIRC according to them, it’s either one or the other

[tacit verge]

well here's an example of someone else hitting the compilation error: https://github.com/rustwasm/wasm-bindgen/issues/4422

[tacit verge]

yeah because their build targetting wasm would have the feature enabled presumably

[finite depot]

Edit suggests they also don’t need the feature

[tacit verge]

not necessarily

[finite depot]

Fair enough

[tacit verge]

i did also hit the error specifically with bevy_cli trying to install wasm-bindgen-cli (before adding the pre-binstall)

but also with my own crate before enabling the feature

[finite depot]

@violet osprey am I just misremembering stuff? Are you supposed to set the rustflag or the rustflag + the cargo feature?

[tacit verge]

here's the job output: https://github.com/benfrankel/pyri_new_jam/actions/runs/15235143471/job/42847946063

[finite depot]

I believe you, I'm just very confused about how this horrid design is supposed to work

[tacit verge]

https://docs.rs/getrandom/0.3.3/getrandom/#webassembly-support

[finite depot]

Damn you're absolutely right

This is horrible

I hate this

[tacit verge]

yeah..

i will try the cfg setup though, i imagine that would also work

btw here's the release workflow before speedup:

and after:

i think the only factor here is -Zshare-generics=y -Zthreads=0

[tacit verge]

https://github.com/TheBevyFlock/bevy_new_2d/pull/423

:/

Check web fails now because it enables the feature but not the cfg

previously it was succeeding because it enabled neither which is.. also wrong i guess?

okay what behavior do we even want?

all web builds / checks should enable both the feature and the cfg?

no RUSTFLAGS merging is insane actually

https://github.com/rust-lang/cargo/issues/5376#issuecomment-2163350032

[finite depot]

About >25% down, nice!

[finite depot]

Lol

[tacit verge]

i wonder if that's real

and if we can use that

[finite depot]

Wow

[tacit verge]

hmm you can't set rustflags in Cargo.toml, it has to be in .cargo/config.toml, but that's supposed to be configured by the user, not the template

so we can't really set rustflags for the user's cargo / bevy commands

unless we start providing an actual .cargo/config.toml

we could move .cargo/config_fast_builds.toml to .cargo/config.toml and only leave the getrandom fix uncommented