Chrome浏览器中Canvas绘制每隔43692次操作出现200000倍延迟的原因探究

Great question—this behavior isn’t about Chrome actively limiting Canvas draws, but rather a deterministic garbage collection (GC) event tied to how Chrome’s Canvas implementation manages memory. Let’s break this down:

What’s causing the 43692-line delay? #

Chrome uses the Skia rendering engine for its 2D Canvas context. In your code, every loop iteration creates a brand new SkPath object (via beginPath() → moveTo() → lineTo()). These path objects are short-lived: after you call stroke(), the path is no longer needed, but it lingers in memory until V8’s garbage collector cleans it up.

The magic number 43692 comes down to two key factors:

• The fixed memory footprint of each SkPath object (and its associated V8 wrapper)
• V8’s GC trigger thresholds, which are tied to memory page allocation sizes

Once exactly 43692 of these path objects accumulate, they fill enough memory pages to trigger a full garbage collection cycle. Unlike fast minor GC events, full GC has to scan and clean up both JavaScript heap objects and their linked native Skia memory resources. This cross-layer synchronization is why the delay is 200,000x longer than a normal draw.

Is this a browser "limit"? #

No, Chrome isn’t intentionally throttling your Canvas draws. This is an unintended side effect of how memory is managed in the browser’s rendering pipeline. The fixed count is just a byproduct of consistent object sizing and predictable GC thresholds.

How to fix this (and avoid benchmarking skews)? #

The core fix is to reduce short-lived path object creation. Since you’re drawing identical lines every time, you can reuse the same path instead of creating a new one per loop:

const ctx = canvas.getContext('2d');
const chartCtx = chart.getContext('2d');
function run() {
  const n = +input.value;
  const times = [];
  
  // Create the path ONCE outside the loop
  ctx.beginPath();
  ctx.moveTo(0, 0);
  ctx.lineTo(100, 100);
  
  const start = performance.now();
  for (let i = 0; i < n; i++) {
    // Reuse the existing path for each stroke
    ctx.stroke();
    times.push(performance.now() - start);
  }
  
  // Chart rendering code remains unchanged
  const maxTime = times[times.length - 1];
  chartCtx.clearRect(0, 0, chart.width, chart.height);
  chartCtx.beginPath();
  chartCtx.moveTo(0, chart.height);
  for (let i = 0; i < times.length; i++) {
    const x = (times[i] / maxTime) * chart.width;
    const y = chart.height - ((i + 1) / n) * chart.height;
    chartCtx.lineTo(x, y);
  }
  chartCtx.stroke();
}
run();

This change eliminates the massive GC spikes because you’re no longer generating thousands of redundant path objects.

For more accurate benchmarking: #

If you’re running performance tests, make sure to:

• Warm up your code (run the loop a few times before measuring) to trigger initial GC cycles upfront
• Average results across multiple runs to account for any remaining GC noise
• Avoid creating unnecessary short-lived objects in your hot execution paths

内容的提问来源于stack exchange，提问作者root