Use Metrics Visualisations from GrandPrix

[camillobruni]

• Use bar-chart to show totals of each iteration
• Use scatter-plots for each metrics and submetrcs
• Use more CSS color variables
• Update scrollbar to match existing color scheme

[camillobruni]

Example graphs:

[camillobruni]

This should be ready for review now. Happy to take feedback.

[rniwa]

• Switched to absolute values by default
• Clicking on any charts toggles all of them between absolute and normalized values

Nice. Being able to switch between two modes is useful. Hovering over each data point to see each data point's raw value seems too hard to do in practice though. Many points are overlapping one another or at the edges.

How about toggling between scatter plots & tabular view. We have an internal performance dashboard, which uses horizontal bar graphs to show variance across different subtests:

Clicking on one of those charts expand it to show the data in tabular form:

This UI is more optimized for comparing two results (A vs B here) but I find this way of visualization & ability to drill down to individual iteration's data to be highly useful.

[bgrins]

I think this looks like a great improvement, thanks @camillobruni!

How about toggling between scatter plots & tabular view. We have an internal performance dashboard, which uses horizontal bar graphs to show variance across different subtests

I agree that looks quite nice, but I wouldn't want to prevent incremental improvements from landing before a new UI was developed. Can this be moved into a follow up issue, where we can discuss in more detail (including the idea of a compare UI)?

[bgrins]

Another idea we could discuss in a follow up is using a dialog element or another overlay to present the detailed info (so that it's not constrained within the default viewport for the runner itself). I did this in a prototype used to research data grids at https://bgrins.github.io/data-ui-tests/?autorun and found it was a nice way to surface more detailed info than trying to fit it into the rest of the page.

[camillobruni]

I like rniwa's suggestion, I definitely use this approach on a separate evaluation page to compare between multiple runs.

Given that we can easily download the data now, the details page should mostly help with assessing the run quality (aka how much noise there is and how data is dstributed).
The scatter plots compress a lot of information into a small area:

• It's easy to see whether we get quantized data

• It's easy to see if you get outliers

• It's easy to see if there is a drift over time

• Maybe a CSV (or tab-separate) download to be easily pasted into a sheet would help with detailed analysis as well?

• I can add a collapsable inline table as well to address the lack of easily reading individual data points

[camillobruni]

• I've added individual table views
• Common prefixes are used as table headers to make the column headers more compact
• Tables and Sub-metrics views can be opened individually
• The background color corresponds to the fraction within [min, max] of each metric

[rniwa]

Hm... can we flip the rows & columns of the tables? Test names are too compressed & horizontal scrolling bar is quite painful to use.

[rniwa]

Are we sure all these values come from trusted sources and not via query parameters, etc...?
I don't want us to have XSS vulnerabilities.

[camillobruni]

• I've now renamed params to viewParams to make a bit more clear that they are not related.
• params.mjs parses all input data (except for params.suites ) to int and bool
• params.suites is checked against a known list of Suites.keys() in runBenchmark

The input values to renderMetricView are only extracted from the metrics themselves which have values coming only from the runner.

[bgrins]

Test names are too compressed & horizontal scrolling bar is quite painful to use.

Another thing we could do is when in the details view set --viewport-width: 90vw; --viewport-height: 90vh. I did this locally when looking at the PR and it's much easier to use than when stuck in the test frame size.

[camillobruni]

• I've now prepared PR Allow custom section sizes #92 to make the details view easier to customise in size (and maximise it)
• I'd prefer the current table layout, so I can easily double check what the outlier values are by scanning across the cell backgrounds
• Hopefully the larger details view should fix this issue

[rniwa]

I think we want to do a bunch of style tweaks but that can be done separately.