next solver on bevy render crate uses 7.3x more peak memory then without next solver

[bgkillas]

trying to build bevy_render from git or latest release with next solver has a warning

warning: overflow evaluating the requirement `IndirectParametersBuffers: Sync`
   --> crates/bevy_render/src/batching/gpu_preprocessing.rs:976:10
    |
976 | #[derive(Resource, Deref, DerefMut, Default)]
    |          ^^^^^^^^
    |
    = note: which requires `bevy_platform::collections::HashMap<TypeId, UntypedPhaseIndirectParametersBuffers, NoOpHash>: Sync`
    = note: which requires `hashbrown::map::HashMap<TypeId, UntypedPhaseIndirectParametersBuffers, NoOpHash>: Sync`
    = note: which requires `hashbrown::raw::RawTable<(TypeId, UntypedPhaseIndirectParametersBuffers)>: Sync`
    = note: which requires `(TypeId, UntypedPhaseIndirectParametersBuffers): Sync`
    = note: which requires `UntypedPhaseIndirectParametersBuffers: Sync`
    = note: which requires `MeshClassIndirectParametersBuffers<IndirectParametersNonIndexed>: Sync`
    = note: which requires `buffer_vec::RawBufferVec<IndirectBatchSet>: Sync`
    = note: which requires `Option<render_resource::buffer::Buffer>: Sync`
    = note: which requires `render_resource::buffer::Buffer: Sync`
    = note: which requires `WgpuWrapper<wgpu::Buffer>: Sync`
    = note: which requires `wgpu::Buffer: Sync`
    = note: which requires `wgpu::dispatch::DispatchBuffer: Sync`
    = note: which requires `Arc<wgpu::backend::wgpu_core::CoreBuffer>: Sync`
    = note: which requires `wgpu::backend::wgpu_core::CoreBuffer: std::marker::Send`
    = note: which requires `wgpu::backend::wgpu_core::ContextWgpuCore: std::marker::Send`
    = note: and so on...
    = help: consider adding a manual `impl` of auto traits like `Send` for intermediate types, if auto traits are involved
    = help: or consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`bevy_render`)
    = note: this lint is attached to the whole crate and can't be disabled on a per-function basis
    = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release!
    = note: for more information, see issue #159228 <https://github.com/rust-lang/rust/issues/159228>
    = note: `#[warn(recursion_depth_exceeding_limit)]` (part of `#[warn(future_incompatible)]`) on by default
    = note: this warning originates in the derive macro `Resource` (in Nightly builds, run with -Z macro-backtrace for more info)

and peaks at around 11gb of memory for me, compared to 1.5gb without next solver, making it quite hard to build on my system due to oom.

Meta

rustc --version --verbose:

rustc 1.100.0-nightly (e7769602a 2026-08-24)
binary: rustc
commit-hash: e7769602aca3770e8d8ea55716becb22e839a579
commit-date: 2026-08-24
host: x86_64-unknown-linux-gnu
release: 1.100.0-nightly
LLVM version: 23.1.0

[dwbrite]

seeing this as well. particularly with bevy_pbr taking at >32GB. Had to go back to 1.99 in the meantime.

[lcnr]

likely related to #161552 (comment) by @analytik

Not sure if this is the right place to report this, but bevy_render, while compiling correctly with the new trait solver, also takes 3700 seconds with it, and 100 seconds with the old one.

Using rustc 1.100.0-nightly (787af2b 2026-08-25) on both host+target x86_64-pc-windows-msvc, with bevy's feature dynamic_linking turned on.

[laundmo]

likely related to #161552 (comment) by @analytik

Quite sure it is, yes. Seems to be related to auto traits recursion depth, and conclusively solved by bevyengine/bevy#25512 which reduced peak memory for me from 14GiB to 1.4GiB.

Since I was messing around with Heaptrack to find out why it uses so much memory, and it turns out getting Heaptrack to work with rustc is a bit annoying (on top of needing to compile rustc myself with debug symbols), heres the Heaptrack profiles: https://share.yadamiel.com/bevy_benchmarks/wgpu-eager-send-sync/ from a rustc compiled with commit e457a7b
use heaptrack --analyze <file> to view them in the GUI, with goodies like a memory-flamgraph