SciChart

Developers evaluating charting libraries for high-performance applications ask the same question: which one actually holds up under real data loads?

We built an open-source benchmark to find out.

What is Chart Bench?

Chart Bench is an open-source JavaScript chart performance benchmark suite that stress-tests popular charting libraries across 13 test cases - including line, scatter, heatmap, candlestick, 3D surface, and multi-chart scenarios.

It measures:

• Frames per second (FPS)
• Time to first render (init time)
• Memory usage
• Data ingestion rate (points/sec)

The benchmark is designed to simulate extreme workloads: millions of data points, real-time streaming, and multiple charts on screen.

It runs locally on your hardware, logs results, and allows JSON export for sharing or comparison.

Clone and run it:
https://github.com/abtsoftware/javascript-chart-performance-test-suite

Libraries Tested

• SciChart.js
• LightningChart.js (v4 + v8)
• Plotly.js
• Highcharts
• Chart.js
• Apache ECharts
• uPlot
• ChartGPU

What It Measures

• FPS under increasing data loads
• Time to first render (ms)
• Memory usage (JS heap)
• Data ingestion rate (points/sec)
• Failure conditions: hangs, freezes, crashes

One Number Worth Knowing

In internal benchmark runs, SciChart.js reached ~40 million data points per second ingestion rate and led in FPS across a majority of tested scenarios on a range of hardware.

Full results - across multiple hardware configurations from high-end GPUs to low-power devices - are published here:

https://www.scichart.com/blog/chart-bench-compare-javascript-chart-libraries/

SciChart is a high-performance charting library for JavaScript, WPF, iOS, and Android, designed for real-time, large-scale data visualisation using GPU-accelerated rendering.

 https://www.scichart.com

🚀 We’re excited to share our latest article on how SciChart delivers the fastest JavaScript charts for React and modern frameworks.

See what’s new in GPU acceleration, real-time streaming, and advanced chart types - built to keep up with serious data.

👉 Read the full article

For .NET desktop developers, the choice between WPF and Avalonia depends mainly on platform strategy.

WPF is still a strong choice for Windows-only enterprise applications. It is mature, stable, deeply integrated with the Windows ecosystem, and supported by years of Visual Studio tooling, documentation, third-party controls, and production use.

Avalonia is designed for modern cross-platform .NET desktop development across Windows, macOS, and Linux. It uses Skia and multi-backend rendering, giving developers more flexibility when applications need to run beyond Windows.

For new cross-platform applications, Avalonia UI can be a strong option. It feels familiar to XAML developers while offering broader platform reach.

For teams with existing WPF applications, Avalonia XPF is especially relevant. It is a commercial WPF compatibility layer built on Avalonia that allows existing WPF apps to run on macOS and Linux with minimal code changes.

For advanced data visualization, the UI framework is only part of the stack. Real-time telemetry, financial dashboards, scientific applications, and other data-intensive systems often depend more on the rendering engine than the windowing framework.

SciChart supports both WPF and Avalonia XPF, helping developers maintain high-performance, real-time data visualization while choosing the platform strategy that fits their application.

In short:

Choose WPF if you are Windows-first and need maturity, tooling, and proven enterprise stability.

Choose Avalonia UI for new cross-platform .NET desktop applications.

Choose Avalonia XPF if you need to move an existing WPF application beyond Windows with minimal code changes.

Read the full technical blog:
https://www.scichart.com/blog/wpf-vs-avalonia/

What causes memory leaks in React apps?

A React memory leak happens when your app keeps references to data, DOM nodes, or processes that should have been cleaned up. Over time, memory usage grows, performance drops, and longer sessions may end in a crashed tab.

In most cases, leaks don’t come from a single bug. They come from small things that accumulate as components mount and unmount.

Common causes of memory leaks in React

These are the patterns developers run into most often:

• Event listeners not removed — attached to window or document, but never cleaned up after unmount.
• Timers still running — setInterval or setTimeout continues executing after the component is gone.
• Unclosed subscriptions — WebSockets, data streams, or observables continue pushing updates in the background.
• Closures holding large data — functions retain references to variables from outer scope, preventing the garbage collector from reclaiming memory.
• Async updates after unmount — a request resolves and calls setState on a component that no longer exists.
• Missing disposal in third-party libraries — some rendering engines (WebGL, WebAssembly, charting libraries) require explicit .dispose() or .delete() calls.

How to fix memory leaks in React

Most React memory leaks are solved the same way: clean up side effects properly.

If you use useEffect, anything that creates a side effect should also remove it:

useEffect(() => {

  const interval = setInterval(() => {

    updateData();

  }, 1000);

  return () => {

    clearInterval(interval);

  };

}, []);

The rule is simple: If your effect starts something, it should also stop it.

How to detect memory leaks in React

1. Use Chrome DevTools (Memory tab)

• Take a Heap Snapshot as a baseline
• Trigger the behaviour (e.g. navigate, mount/unmount components)
• Force garbage collection
• Take a second snapshot
• Compare the two

Focus on:

• Objects that increase but don’t go away
• Detached DOM nodes (elements no longer in the UI but still in memory)

2. Use the Performance tab

• A healthy app → memory rises and drops
• A leaking app → memory rises and never fully drops

React memory leak checklist (quick audit)

1. Do all useEffect hooks return cleanup functions where needed?
2. Are event listeners removed on unmount?
3. Are timers cleared?
4. Are WebSocket or stream connections closed?
5. Are requestAnimationFrame loops cancelled?
6. Are fetch requests aborted when components unmount?
7. Are large datasets scoped correctly?
8. Do third-party libraries provide a dispose/delete method — and are you calling it?
9. Are you preventing state updates on unmounted components?
10. Have you compared heap snapshots before and after reproducing the issue?

Why memory leaks get worse in data-heavy apps

If your app handles large or real-time datasets, leaks become more noticeable.

Some libraries keep large datasets in JavaScript memory. If references persist, the garbage collector cannot reclaim that memory.

At that scale, memory management isn’t just an implementation detail — it’s part of your architecture.

In short:

• Most React memory leaks come from uncleaned side effects in useEffect
• The common causes are listeners, timers, subscriptions, and async updates
• Use Heap Snapshots in Chrome DevTools to confirm leaks
• Data-heavy apps amplify the problem
• A simple cleanup habit prevents most issues

Memory leaks are rarely mysterious. They’re usually leftover work that never got cleaned up.

React won’t manage that for you — but once you know where to look, leaks are predictable and fixable.