Add history graph to benchmark detail

[Kobzol]

This PR adds a mini 30 day history graph to the benchmark detail component introduced in #1689. This should help us quickly access the history of a specific benchmark.

Loading of these graphs is cached on the client side, i.e. the same graph will only be loaded once (on-demand) per page load. @Mark-Simulacrum If you're worried about the server load that could be caused by this, I can also add a cache on the server side.

graph.mp4

I didn't use the single graph endpoint introduced in #1054, because it doesn't return the commit list, and thus the response cannot be directly used with the existing code to render a graph. And since the /graphs endpoint can actually return just a single graph, I think that the single graph endpoint is basically redundant at this point.

[Mark-Simulacrum]

I haven't looked at the code yet, but I don't understand the client side cache - isn't each graph on the compare page distinct?

[Kobzol]

By default, Vue components are destroyed when they stop being rendered. This means that if you would "spam" clicking on the arrow for the same benchmark row, it would reload the graph from the server on each display of the detail component. This is what the client side cache prevents.

[Mark-Simulacrum]

I think that's fine for now then. We only have a server side cache for the index.html default graphs endpoint, and I'm not even sure how critical that is.

[Kobzol]

I added a comment to the code to explain why the client side cache is there.

[Kobzol]

Changed the graph kind based on @lqd's suggestion.

[lqd]

Sweet!

[rylev]

Would it be possible to somehow detect wether there are future results for the given test cases and show future results? This can be useful for determining noise. If the change is not reversed in future results, it's easier to determine it might be noise.

[lqd]

For triage purposes I also have to do this a lot, and had already asked if this feature could e.g. show up to the next 10 commits following the end range, to see whether it was a sustained change or things returned to steady state. I believe the short answer is yes, but maybe not in this PR per se.

[Kobzol]

Showing future commits is a good idea, I wanted to do it in a future PR, but I guess that if we find a reasonable way to implement, we can include it here outright.

So, how should it work? Some ideas:

• Always show P days, F future ones (up to F=P / 2), and P-F past days. Where F is determined in how many "future days" exist at the current timestamp.
• Always show P past days, and additionally F future days, up to F = P.

[lqd]

Honestly, just having some future data would already be awesome, so whichever way is the easiest to do. And we can iterate in the future, once we have experience with it.

Ryan/Mark/Felix may have a different process, but some thoughts:

• we usually show charts of the last 30 days, so this number of past days could be fine
• noise swings can calm down quite quickly (though maybe the dynamic threshold could be helping in hiding some of that tail) and sometimes only a few future commits are enough (let alone full days worth of commits). They do the triage weekly, so <= 7 days seems safe for that process, and 3-4 could be nice I guess. But like I said, if we find it's too much or not enough we can easily adjust these later.
• if we have both past and future data, it would be nice to easily see the currently benchmarked commit on the graph, or it could be hard to spot. I don't know if that's easy to do. We have some support for vertical ranges (a pink region) for interpolated data, so even just separating the future data with such a differently colored background could be a solution.
• another piece of information I try to gather is "how does this look now ?" on the individual benchmark charts, and change the end range. I wouldn't ask for data to load dynamically in an infinite scrolling graph: it would be great if there was a link/button opening an individual chart with the same -30 days start range and $now as the end range :). But again we can easily add such a thing later.

[Kobzol]

I implemented a graph that can take a look into the future. The graph currently always shows 30 days, up to 15 days into the future, relative to the commit (if the future has happened already), and up to 30 - days shown in the future days in the past.

For try builds, it shows the same graph as before, -30 days until the try commit.

This is how it now looks for an older master commit:

The red line is the date of the commit.

[Kobzol]

another piece of information I try to gather is "how does this look now ?" on the individual benchmark charts, and change the end range. I wouldn't ask for data to load dynamically in an infinite scrolling graph: it would be great if there was a link/button opening an individual chart with the same -30 days start range and $now as the end range :). But again we can easily add such a thing later.

I have another PR prepared on top of this one, which adds links to the benchmark detail, I'll add this to that PR.

[rylev]

I personally think 30 days is too long, but I don't want to block this PR. We can always adjust timeframes in the future. Thanks for working on this!

[lqd]

FWIW we recently had a case in rust-lang/rust#114492 with similar noisy behavior that had happened 15 days in the past.

edit: and which would have looked like this

[lqd]

This is going to be super helpful!

I'll look into the background-color regions thingy I mentioned, there's no need to block this PR: the dashed vertical line can collide/hide the graphed data itself.

(I can't easily test the behavior on a try build since that requires server-side changes, so rust-lang/rust#102099 (comment) understandably shows up locally as a real merge, with future data and dashed line)

If there are tiny issues, we can fix them.