Monitoring and improving compiler performance over the medium to long term

The compiler performance team is largely focused on performance changes on a per pull request basis. The procedures we have in place today are largely focused on ensuring that individual pull requests don't negatively impact compiler performance and if they do, that this reasoning is justified.

The only regular procedure for tracking performance at a granularity larger than the pull request is the weekly triage report. However, the report is itself largely focused on each pull request individually and does not examine how compiler performance has changed as a whole since the last triage report.

While such procedures can ensure long term positive changes to compiler performance, it is currently rare that the compiler team examines longer term trends. We should easily be able to answer how compiler performance is changing over several time periods (1 month, 6 months, 1 year) as well as provide the tools for the compiler team to undertake longer term initiatives to improve compiler performance that span beyond short term performance triage.

As our procedures for performance monitoring of individual pull requests solidifies, it's time to take a step back and examine how we can expand procedures to ensure that longer term compiler performance is actively monitored and improved.

As a start to this, we've opened #1044 which examines how we can improve the triage process to not only ensure we are on top of individual changes to compiler performance, but also start building knowledge of how compiler performance is changing over time.

Start by reading issue #1044 and the existing weekly triage report, which are the only current procedures named here. Define how compiler performance should be tracked over one month, six months, and one year, and what longer-term improvement process would make those trends actionable.