Slow compilation of actix-web routes

[Nutomic]

I noticed that Rust is extremely slow to compile a rather simple file containing route definitions for the actix-web webserver. It has 200 lines of imports, 250 lines of code and no macros, yet takes ~60s to compile. Duration is the same on Rust 1.81, 1.86 and nightly-2025-04-27.

Here is an excerpt from the profiling data, and you can also view the .mm_profdata.

Item	Self time	% of total time	Time	Item count	Incremental result hashing time
layout_of	29.25s	42.066	111.38s	123703	32.73ms
normalize_canonicalized_projection_ty	17.28s	24.851	18.07s	15554	5.31ms
codegen_select_candidate	9.16s	13.173	9.39s	28989	9.75ms
LLVM_module_codegen_emit_obj	5.59s	8.042	5.59s	256	0.00ns
LLVM_passes	2.13s	3.069	2.13s	1	0.00ns
codegen_module	1.40s	2.009	4.43s	256	0.00ns
evaluate_obligation	951.66ms	1.369	1.03s	47932	7.69ms
items_of_instance	301.15ms	0.433	56.05s	57443	34.90ms

Whats strange is that the same file on the main branch takes only ~25s to compile (which is still too long). There it is part of the main binary crate.

To reproduce run:

git clone https://github.com/LemmyNet/lemmy.git --recursive --branch api-routes-crate
cd lemmy
cargo build --timings -p lemmy_api_routes

[lqd]

The above is entirely coming from the layout sanity checks, which is very unexpected.

It looks to be taking a long time to compute uninhabitedness for some of the big types in this crate (big coroutines, a lot of the time), sometimes multiple seconds for a single type. Overall, locally with the latest master commit at the time, the layout sanity checks take 66 seconds with the type-level uninhabitedness check, compared to 220ms without (using try build artifacts of the proposed change below).

@RalfJung would it be acceptable if I moved this uninhabitedness assertion (added in #96872) a bit down, to be gated by cfg(debug_assertions) like the other expensive layout sanity checks in this function?

[RalfJung]

Isn't that query-cached? If not, maybe it should be? Or are we really only calling is_privately_uninhabited there?

Cc @oli-obk @compiler-errors

[lqd]

The layout_of query is supposed to be cached, for both unnormalized and normalized types, AFAICT. What's being computed is unexpectedly slow (the is_privately_uninhabited check is causing the slowness), so caching doesn't help unfortunately.

Why the uninhabitedness check is slow is unclear (michael mentioned he may look at it), but these look to be very big coroutines (some of the big DB query types are also slow) and maybe some additional caching could help, but the easiest/lowest hanging fruit is likely treating this sanity check like the other expensive checks, as debug assertions.

(There seemingly are also other compilation performance regressions related to that crate, so there may other be compounding factors that make things worse. We'll know more soon about this)