Nicholas Nethercote
Nicholas Nethercote
There was some [discussion](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/.60log.60.20build.20script.20removal) about this on Zulip. One recent comment: > Hm. It looks like log's build.rs is wrong in any case: > - atomic_cas is set for thumbv4t-none-eabi,...
I can't reproduce this. I don't get any errors in the terminal output.
I can reproduce when visiting the status page locally. I don't think I've ever done that before.
Ok, `compile-benchmarks` is good enough.
I see https://perf.rust-lang.org/dashboard.html is now up, thanks to #238. I think having a per-version compile time tracker is a very good thing. But I also have some major concerns with...
Log scales are visually misleading. In this case, compile time increases are visually diminished and compile time decreases are visually exaggerated. Log scales are a reasonable choice when your values...
> Note that the geometric mean is just the arithmetic mean on a log scale I know what geometric mean is, and arithmetic mean, and a log scale, but I...
> One potential problem with the arithmetic mean is that benchmarks for big crates (like style-servo or script-servo) make improvements in smaller crates almost invisible, while it's not necessarily true...
Any progress here?
Something relating to codegen unit boundaries, maybe?