[charts] Improve performance of rendering ticks in x-axis

[bernardobelchior]

Depends on #16548.

Part of #10928.

Measuring the size of text using getBoundingClientRect is expensive, especially when appending elements one by one to the DOM, which is what we're doing at the moment.

Knowing that, this PR focuses on reducing the number of times we actually measure text. In the case of tick labels in the x-axis, this is done by:

1. Checking whether the center of label would overlap with a previous label (or the minimum gap between labels);
2. Checking whether the center of the label would be outside the visible area.

Only if these two checks are true do we actually measure the text. This helps us reduce the number of measurements, improving performance for when rendering many labels.

Bear in mind that we cache the measurements, so the impact on performance will be less if we're measuring the same strings repeatedly.

Results

Rendering the following bar chart (from the "BarChartPro" benchmark) in a Vite application using production builds:

Before

401 cache misses, around 20ms spent measuring text.

After

99 cache misses, around 7ms spent measuring text.

For this example, this means a 75% reduction of measurements taken and around 65% reduction in time spent measuring.

[bernardobelchior]

Rudimentary way to check how long we're spending in text measurements.

By running domResults, you should see how many times (count) and how long it took in ms (time) to measure all the text that was measured so far. These values only include the cache misses.

[bernardobelchior]

Assumed a gap of 8px for testing purposes. Seems a reasonable default:

[mui-bot]

Deploy preview: https://deploy-preview-16536--material-ui-x.netlify.app/

Generated by 🚫 dangerJS against 37c1fbb

[bernardobelchior]

If there isn't enough space between the end of the last text plus the gap and the center of this tick, then we don't even need to calculate the width because we already know it won't fit.

[bernardobelchior]

Don't calculate label width if the tick is outside the visible area (useful when zooming)

[bernardobelchior]

The results are still early and may change, but look promising.

These changes reduced the number of actual DOM measurements from 401 to 83, and the time spent measuring from 126ms to 33ms (MacBook Pro M4 Pro, 48GB RAM, 6x slowdown), which is a 3.8x improvement.

This is the component I'm using for benchmarking:

import { BarChartPro } from '@mui/x-charts-pro';

const dataLength = 400;
const data = Array.from({ length: dataLength + 1 }).map((_, i) => ({
  x: i,
  y: 50 + Math.sin(i / 5) * 25,
}));

const xData = data.map((d) => d.x);
const yData = data.map((d) => d.y);

export default function BarChartProBench() {
  return (
    <BarChartPro
      xAxis={[{ id: 'x', scaleType: 'band', data: xData, zoom: { filterMode: 'discard' } }]}
      initialZoom={[{ axisId: 'x', start: 25, end: 75 }]}
      series={[
        {
          data: yData,
        },
      ]}
      width={500}
      height={300}
    />
  );
}

[alexfauquette]

Looks already pretty solid. I added a commit to fix the benchmark. Your PR modifies which label is visible or not. And it impacted the labels the benchmark test was looking for to compute the rendering duration

Is their something missing to have this as ready for review?

[bernardobelchior]

Looks already pretty solid. I added a commit to fix the benchmark. Your PR modifies which label is visible or not. And it impacted the labels the benchmark test was looking for to compute the rendering duration

Thanks!

Is their something missing to have this as ready for review?

Yeah, I'm experimenting with other approaches. You can see them here and here.

The reason I don't want to merge this yet is because my investigations unveiled a bug in the measurement logic. The default label is being measured as 18px, when it is actually 21px. The gapRatio of 1.2 fixes the issue, but this PR removes that ratio. If someone is using minGap={0}, they might see overlapping labels, so I'd rather fix the issue first, then open this PR for review.

This lead me to investigating how to performantly and accurately measure the width and height of text, which is what I'm exploring in those PoCs. Feel free to give your opinion. I think they're ready for some feedback 😄

[github-actions]

This pull request has conflicts, please resolve those before we can evaluate the pull request.

[codspeed-hq]

CodSpeed Performance Report

Merging #16536 will not alter performance

_{Comparing bernardobelchior:x-axis-improve-text-measure-perf (37c1fbb) with master (ff10228)}

Summary

✅ 6 untouched benchmarks