Description
In order to benchmark the performance gain in elastic-charts, we should add telemetry marks on at a series of specific processing points in the chart.
Looking at elastic/kibana#182551 is possible to identify a set of at least 3 phases in elastic-charts where the time spent can be significant with the increase of the number of data points:
- the initial data alignment/formatting (a data processing phase where data tables are created based on the passed input, domains are computed, and stacking/formatting/grouping are done)
- a subsequent phase that generates an object per geometry (line, area, bar, point), their screen positions, their color, their rendering order
- a final phase where this is drawn on the canvas
The first 2 phases can also be broken down into smaller chunks, but for now, I believe this is enough to understand time improvements.
We also need to understand that telemetry can change significantly in different browser contexts, and there isn't a stable way to rerun the same test with exactly the same CPU and memory conditions then the previous test. The differences can be in the order of 10/50ms within our current rendering time is a lot and can hide improvements. So for now better to keep the phases as large as possible.
The strategy for the telemetry, that will be collected in Kibana, could be:
- create specific PerformanceMark in the charts (probably only in development environment) and generate the required measures
- Within the EBT journeys, extract these performance measurements and use them in the telemetry.
Some general suggestions:
- we should prefix all our marks with strings that help identify the nature of the mark (elastic-charts vs lens) and the chart itself (the chartId).
- to avoid memory consumption remember to clean the marks after sending them to the telemetry
- be aware of possible marks duplicates caused by multiple re-renders