rust-lang / rustc-perf

Website for graphing performance of rustc

Home Page:https://perf.rust-lang.org

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Selecting earliest commit in graph throws an error

Zentrik opened this issue · comments

image
If I select the left most commit in this graph, the url is 'https://perf.rust-lang.org/compare.html?start=null&end=37b65339c8cf1d18e331f184dbf70bbddcb1e4f7&stat=instructions:u' which throws an error due to start being null.

This seems to affect all the graphs on the site.
Sorry if intended.

Not intended, and you don't have to apologize in advance 😆

I guess in this situation, we should remove the start query param, right?

Well, in theory it would be best if we gave it the actual previous commit as start, but that will probably be quite difficult to get (unless we artificially remove the leftmost commit from the graph, so that we have the previous entry for all commits in the graph, lol). So either that, or just remove the start parameter in this case.

Ah, maybe we could do that!

We can request data for the range [start - 1, end] to include the commits we need. Then find the first commit which is right before start (firstCommit), adjust the data range back to [start, end] and pass firstCommit to renderPlots.

Well, that could work, but start - 1 is load bearing :) You don't have a way to easily find the previous commit from the frontend. You could automatically return more data from the backend though, or simply trim the graph to avoid displaying the left-most commit, which is maybe the easiest option.

I think we just need to use findIndex(c => c[0] >= start_in_seconds). Then, assuming everything works correctly, firstCommit should be set to index - 1.

I'm not sure if I understand what do you mean, as we don't have any list of commits in the frontend before we actually ask the server to give us the graph data. So when we ask the server for graph data, the only thing that we can say is [start, end], and we can compute start to be a specific day, and subtract/add days to it (but not individual commits).

In any case, it would probably be easier to discuss this over actual code :)

Ah, I didn't describe it clearly enough. I would expect something like the following in buildGraphs:

  const start = new Date(graphRange.value.start).getTime() / 1000;
  const firstIdx = detail.commits.findIndex(c => c[0] >= start);
  const firstCommit = firstIdx > 0 ? detail.commits[firstIdx - 1] : null;
  const commits = firstIdx > 0 ? detail.commits.slice(firstIdx, detail.commits.length) : detail.commits;

Oh, I see, then we probably mean the same thing 😆 I think that firstIdx can be always just 1? Since the commits from the server come sorted.

Actually, it could be a number greater than one, since there might be more than one commits in a day.

I think that days are not important here. We ask the server for some graph range, it returns us N commits. We then display all N commits in the graph. The issue is that the very leftmost commit (i.e. commits[0]) doesn't have a previous commit that could be used for the start parameter in the generated URL, which produces an invalid link.

So we can always display only commits[1:] (in Python notation :) ) in the graph, and therefore the leftmost commit will always have a previous commit (commits[0]), and thus the link should work for all points in the graph.

Yes, what I meant to say is that the return graph could potentially include commits like this: [ds-1, ds-1, ds-1, ds, ..., de] where ds represents the starting commit and de represents the ending commit.

Yeah, that could also work, but I would rather just modify the UI with what is probably a quite simple change (just display commits[1:]), rather than do some more complex computation on the backend.

Oh actually, what I demonstrated above only changes the frontend part, without needing to modify the backend.

But where do you get ds-1, since we don't have any information about that? 🤔

Actually, would you like to send a PR? 😆 I think that we're just running in circles here, without seeing the specific approach :)