many major compile-time perf regressions in jld-day15-parser

[brson]

Look at the graph.

[brson]

I'm having a hard time getting the rustc-perf comparison page to tell me which passes regressed.

[eddyb]

Also see #33889.

[brson]

The rustc-perf site changed and the link no longer goes somewhere useful.

[durka]

Fixed link (s/index.html/graphs.html)

[eddyb]

@brson What I do is use Tab + Spacebar to bisect the pass set.

Meaningful variance by passes (can also see them combined):

• macro loading: 0.003s -> 0.018s
• item-bodies checking: 1.6s -> 0.7s -> 1.1s -> 1.3s
• translation: 40s -> 47s -> 33s -> 74s -> 81s

EDIT: Ahh, missed the type-checking one. Also, there's some interesting correlation, almost as if the whole compiler was running faster for a short time. Changes to jemalloc? #33425? The systems running these benchmarks?
It would be useful if we had more metadata. Are the dates nightlies? Then we can probably use the builder logs to find out the commit ranges for each change.

[eddyb]

A rough approximation for the strange dip is this range of commits, which includes #33491. Not much else of relevance AFAICT.

EDIT: This range might also include the large regression after the dip.

[eddyb]

Looks like the first jump in translation, 40s -> 47s is indeed caused by #33425. Or at least, the date matches.

[eddyb]

For the last jump in translation, 74s -> 81s, I have another approximate range of commits with #33602 as a potential culprit (also my fault? 😞).

@nrc Could we run the same process that generates the graphs on individual PRs, to confirm such regressions?

[arielb1]

This seems to be fixed on the latest revision - translation takes 5s on my laptop. Probably #33816 too. I will wait for next nightly before closing.

[nrc]

@eddyb there is no way to do that, sorry. It's a feature nmatsakis has also requested. Easiest way to simulate is just to run time-passes locally before and after the PR.

[arielb1]

@nrc

I think we should do benchmarks for each bors merge and store that. Maybe even do that on the buildbots?

[eddyb]

@arielb1 Sadly some of the buildbots share resources so they're not deterministic at all.

[nrc]

@arielb1 we don't have the hardware for that at the moment. We could do this if we decided it was useful enough to justify buying and maintaining more hardware, but I don't think that is the case for now.

[nikomatsakis]

This chart suggests that our compilation time has (very recently, in the last few days) gotten better since Dec of 2015, which seems to be the point that @brson was originally comparing against.

[brson]

Sweet.