rust/compiler/rustc_data_structures/src/vec_cache, branch autohttps://github.com/rust-lang/rust
http://git.dreamy.place/mirrors/rust/atom?h=auto2025-06-05T19:12:28+00:00Simplify `vec_cache::tests::slot_index_exhaustive` by pulling out 0 case2025-06-05T19:12:28+00:00Josh Triplettjosh@joshtriplett.org2025-06-05T19:06:21+00:00urn:sha1:9837c3c3f8accf763704cc56e2b13398e86db282
`slot_index_exhaustive` has additional complexity in its loop that only
applies for index 0. Pull that case out of the loop.
Rustfmt2025-02-08T22:12:13+00:00bjorn317426603+bjorn3@users.noreply.github.com2025-02-08T22:12:13+00:00urn:sha1:1fcae03369abb4c2cc180cd5a49e1f4440a81300Improve VecCache under parallel frontend2024-11-15T23:20:32+00:00Mark Rousskovmark.simulacrum@gmail.com2024-05-05T23:57:24+00:00urn:sha1:da58efb11df229eac6eb727c2884546310f9ffde
This replaces the single Vec allocation with a series of progressively
larger buckets. With the cfg for parallel enabled but with -Zthreads=1,
this looks like a slight regression in i-count and cycle counts (<0.1%).
With the parallel frontend at -Zthreads=4, this is an improvement (-5%
wall-time from 5.788 to 5.4688 on libcore) than our current Lock-based
approach, likely due to reducing the bouncing of the cache line holding
the lock. At -Zthreads=32 it's a huge improvement (-46%: 8.829 -> 4.7319
seconds).