3 ms·

> I read that the rust compiler team checks itself against some massive list of popular crates to check it doesn't break anything. Yes, that "massive list" bei

> I read that the rust compiler team checks itself against some massive list of popular crates to check it doesn't break anything. Yes, that "massive list" being every single crate in the crates.io repository. > Would it be a reasonable use of resources to run all those test suits and identify hot spots for community wide optimization? I believe the approach on the perf side of things has been to take reports on crates that are particularly slow (even at one particular part of the compiler) and create benchmarks from those. I believe this is partly because running against every single crate would be too slow, and partly because it would be a moving target (as new versions of crates are released) and thus would make it hard to track performance accurately.

estebank 4y ago
As crater was already linked to in a sibling comment, the performance suite dashboard can be seen at https://perf.rust-lang.org/ https://perf.rust-lang.org/, and the suite itself at https://github.com/rust-lang/rustc-perf/tree/master/collector https://github.com/rust-lang/rustc-perf/tree/master/collecto...
tialaramex 4y ago
I think what ZeroGravitas was getting at was the idea of optimising the actual software rather than the compiler. For example you could imagine noticing that people make a lot of Vecs with 400 or 800 things in them, but not so many with 500 or 1000 things in them and so maybe the Vec growth rule needs tweaking to better accommodate that.