Improve compile times by using type erasure + a worrying look into the future of rustc

[HugoPeters1024]

While playing around with rustc's upcoming new trait solver on bevy , I noticed that it improved the performance of some of Bevy's subcrates, but the total compilation time was much worse due to wesl.

Turns out that wesl interacts surprisingly bad with this new solver. I was able to find very simple patch that improves this a bunch, as well as improves the compile times under the legacy solver:

Solver	naga-ext	Version	Total	Frontend	Codegen
Current solver	enabled	Before	6.7s	4.6s	2.1s
Current solver	enabled	After	5.0s	2.6s	2.3s
Next solver	enabled	Before	164.4s	161.5s	2.9s
Next solver	enabled	After	43.0s	40.5s	2.5s

A critical read might say that the next solver is still a major performance setback when it comes to this crate. And they would be right! I will also report this regression upstream (DONE HERE) at rustc in the hope that they can use wesl as a case study before rolling out the new solver as the default.

Tradeoffs

I believe that these boxes do incur a slight runtime cost due to dynamic dispatch. Under the legacy solver, this patch not an extremely convincing win.

Benchmark command

Timings were collected from clean target directories using Cargo's timing
report. The new-solver measurement used a locally built nightly/dev compiler
that supports -Znext-solver.

# Current solver, with `naga-ext`
CARGO_TARGET_DIR=<checkout>  \
  cargo build -p wesl --features naga-ext --timings

# Experimental next-generation solver, with `naga-ext`
RUSTFLAGS='-Znext-solver=globally' \
  CARGO_TARGET_DIR=<checkout> \
  cargo build -p wesl --features naga-ext --timings

So what's next?

Not sure, tbh. I just wanted to get this out there.

[github-actions]

Welcome, new contributor!

Please make sure you have read our contributing guide and we look forward to reviewing your pull request shortly ✨

[k2d222]

Very interesting finding! 😮

I need more evidence and data as to what is causing the regression. Intuitively I would have guessed it is caused by the large amounts of code generated by the parser (lalrpop) in wgsl-parse, but your PR points at something else entirely. The quote stuff you point at is a DSL language designed to create iterators over nodes in WESL's syntax tree. It is (almost) only used in file crates/wesl/src/visit.rs, where there is indeed a fair bit of trait solving involved to look up implementations of the Visit trait and then produce the Iterator impl.

Even with your fix, going from 5s to 43s is not acceptable.
So I'll wait for more data and/or investigate myself when I get the time.

[k2d222]

Here are my numbers:

Solver	naga-ext	Version	Total	Frontend	Codegen
Current solver	enabled	Before	11.5s	8.1s	3.4s
Current solver	enabled	After	8.5s	5.2s	3.3s
Next solver	enabled	Before	11.6s	8.2s	3.4s
Next solver	enabled	After	7.9s	4.8s	3.1s

My specs:

• OS: Fedora Linux 44 (Workstation Edition)
• Rustc: rustc +nightly --version -> rustc 1.100.0-nightly (c54751567 2026-08-22)
• Proc: AMD Ryzen™ 5 3600 × 12

So for me, your PR does improve compile times significantly, but I could not reproduce your issue as the next-solver didn't change anything. (or am I running it wrong?)

[BenjaminBrienen]

cargo +nightly build -p wesl --features naga-ext --timings	18.33s
RUSTFLAGS='-Znext-solver=globally' cargo +nightly build -p wesl --features naga-ext --timings	18.31s

cargo 1.100.0-nightly (e8cb624d5 2026-08-22)

             /////////////                 benjamin@pop-os
         /////////////////////             ---------------
      ///////*767////////////////          OS: Pop!_OS 24.04 LTS x86_64
    //////7676767676*//////////////        Host: X670E AORUS MASTER (-CF)
   /////76767//7676767//////////////       Kernel: Linux 7.0.11-76070011-generic
  /////767676///*76767///////////////      Uptime: 1 day, 14 hours, 18 mins
 ///////767676///76767.///7676*///////     Packages: 2230 (dpkg), 11 (flatpak-system), 12 (flatpak-user), 61 (nix-default)
/////////767676//76767///767676////////    Shell: zsh 5.9
//////////76767676767////76767/////////    Display (SAM73CE): 5120x1440 in 57", 240 Hz [External]
///////////76767676//////7676//////////    DE: COSMIC 1.0.0
////////////,7676,///////767///////////    WM: cosmic-comp (Wayland)
/////////////*7676///////76////////////    Theme: Yaru [GTK3]
///////////////7676////////////////////    Icons: breeze-dark [Qt], Yaru [GTK3]
 ///////////////7676///767////////////     Cursor: Adwaita
  //////////////////////'////////////      Terminal: code 1.134.0
   //////.7676767676767676767,//////       CPU: AMD Ryzen 9 7950X (32) @ 5.88 GHz
    /////767676767676767676767/////        GPU 1: NVIDIA GeForce RTX 3070 [Discrete]
      ///////////////////////////          GPU 2: AMD Raphael [Integrated]
         /////////////////////             Memory: 24.90 GiB / 61.94 GiB (40%)
             /////////////                 Swap: 15.95 GiB / 20.00 GiB (80%)
                                           Disk (/): 1.02 TiB / 1.78 TiB (57%) - ext4
                                           Disk (/recovery): 3.41 GiB / 3.99 GiB (86%) - vfat
                                           Local IP (enp13s0): 192.168.2.15/24
                                           Locale: en_US.UTF-8

[hukasu]

just a reminder for anyone else wanting to post timings, each run needs to be from clean state (after cargo clean)

it is probably already forced because a change in solver might invalidate all of the artifacts, but just in case

[HugoPeters1024]

Hey that's surprising....

Looks like there is one variable that I forgot to report: the exact rustc revision I was working with. I thought I was working off the latest main, but I was a week or so behind. And indeed, it appears this issue is real, but also has been patched very recently:

Rustc	Solver	Wesl total	Frontend	Codegen
1.97.1 (2026-07-14)	current	6.0s	4.0s	2.0s
1.97.1 (2026-07-14)	next	142.4s	139.8s	2.6s
nightly-2026-08-22	current	7.0s	4.7s	2.3s
nightly-2026-08-22	next	6.7s	4.7s	2.0s

I suppose that puts a nail in the coffin of this PR. It's an interesting case study, but 0.3s compile time wins are almost certainly not worth the cost of dynamic dispatch.

Thanks for thinking along everyone!