Display results as HTML

[vaerlor]

Create a HTML view for the results.

The view should:

• display the current results
• display a history of results
• display a flame graph?

The current results are of type BenchmarkSummary. It should be possible to work with this type from memory, right after the export has been run.
To display a history, it should be possible to use the Renderer without running the exporter first. This means, it should be possible to import results from files.
Research what a flame graph is and how to display it based on the BenchmarkSummary.

Issue will be further refined as development continues.

[vaerlor]

Hey @atmoos, I started again with this Issue. I remember we had a talk about the way the Display Mode is passed to the interface, but I'm not sure about the details. Was it something along the lines, that you'd like the Mode to be extensible, so that if a user has it's own mode with it's own implementation, he can still use the Rendering part?

FYI, the current interface looks like this:

public interface IDisplay
{
   Task Render(IEnumerable<BenchmarkSummary> summaries, Mode displayMode, CancellationToken token = default);
}

The mods were defined as Enum, thus the library would need to be recompiled to extend them.

public enum Mode
{
    HtmlCurrentResults,
    HtmlHistory,
    HtmlEvolution
}

[vaerlor]

A simple alternative would be:

public interface IDisplay
{
   Task Render(Action<IEnumerable<BenchmarkSummary>> display, CancellationToken token = default);
}

We could then provide some convenience methods to Display the current benchmark summary as HTML, history, etc.

[atmoos]

Nice that you picked it up again :-) I hope to find some time to continue work myself.

As per your question. Why not just provide the Render method in its simplest form:

public interface IDisplay
{
   Task Render(IEnumerable<BenchmarkSummary> summary, CancellationToken token = default);
}

Depending on the intended usage that method could even be a static method. (But that's not really important)

I am in fact also completely open to just see what you come up with, even using the proposed enum. :-)

[vaerlor]

Regarding your suggestion: imagine there are 3 different implementations for the IDisplay interface: one for displaying a styled HTML page with the current result – DisplayHtml; one for displaying how the benchmark evolved in time, a history – DisplayHistory; and finally, the FlameGraph. Each of these classes has a different implementation of the Render method. How would the project know which implementation to call in case we want to display just the HTML?

Since we don't use dependency injection, we need some kind of mechanism so that the project knows how the classes DisplayHtml, DisplayHistory and FlameGraph implement IDisplay.
Next, we need some kind of "render engine" which knows that it will receive as Input an IEnumerable<BenchmarkSummary> and has to perform an action to render the summaries.
Since we want to leave the interface open for extensions, I was thinking of restricting the interface just a bit, by describing the method the render engine will have to call. If we do this, every class is responsible for designing it's own display method. The render engines' job is just to call this display method. This display method was represented by the Action<IEnumerable<BenchmarkSummary>> display delegate.
If I want to display the HTML, the class implementing the interface will provide it's own implementation of the render method as parameter. Therefore, if someone calls DisplayHtml, the engine will display exactly that.
We will provide some extension methods, so that the final user will call something simpler and won't have to provide it's own implementation.
This is how I was thinking of having multiple implementations, not coupling it with any enum (which I agree is a bad decision) and still leave the interface open for extensions.

I suppose with your suggestion, we would need some kind of factory which ties a concrete implementation, say DisplayHtml with the actual HTML. I'm curious to see how you envisioned coupling the interface with the implementation!

[atmoos]

I understand your arguments. Let's go ahead and implement it using the enums. We can then discuss the solution in person during the PR.
If we feel the enum is a good fit, we merge. If not, we refactor a bit :-)