最快的 JavaScript 图表

There are two very different things people mean when they call a chart fast, and charting libraries are built for one or the other.

Loading a large data set once, then panning and zooming around it. The data never changes after it arrives.

Replacing the data continuously, where every value is new on every frame. A rolling acquisition window, an oscilloscope sweep, filtered or recomputed data rebuilt before it is drawn.

Almost every published JavaScript benchmark measures the first one. ProEssentialsJS is built for the second, and this page shows what that is worth.

Three workloads, and the names are not ours

LightningChart publishes a benchmark comparing twelve JavaScript charting libraries. They split line charts into three application types, and their categories are the clearest framing available:

In their words, refreshing performance is measured as "refresh rate, how fast dataset can be refreshed". That is the workload this page is about, and it is the one that matters if your data is live.

What ProEssentialsJS does on the refreshing workload

Five signals on five stacked Y axes. Every value re-passed into the engine and the entire chart redrawn, on every frame.

Measured on an RTX 3090, a card from 2020, at 1528x917. Not a workstation, and not this year's hardware.

Source for the LightningChart figures.They are LightningChart's own published numbers, not a Gigasoft measurement of their product. The refreshing test of 1,000,000 points at 10 Hz, the static and appending tests, and the three category names above are all taken from LightningChart JS Line Charts Performance Comparison, published by LightningChart Ltd, which compares twelve JavaScript charting libraries including Highcharts 9.1.0, SciChart JS 2.0.2115, ECharts 5 and Plotly.js 1.58.4. The document is published on their site and their test method is published on GitHub. Gigasoft has not run LightningChart software to produce any number on this page.

What the others actually publish

SciChart.js is a WebAssembly engine and a serious one. Its realtime demo appends 1,000 points every 10 milliseconds, which is 100,000 new points per second onto a buffer that is retained between frames. Its headline figure, one million points in under 15 milliseconds, is a load. The 10 millisecond redraw it quotes is explicitly once the data has already been loaded.

Highcharts renders SVG, which means one DOM element per point. Their own documentation says that adding hundreds of thousands of points means adding hundreds of thousands of SVG elements to the DOM, that the process is slow, and that it "slows down all interaction with the chart, such as the responsiveness of the tooltip while hovering". Their Boost module is a WebGL renderer that works alongside the SVG one and hands rendering back to SVG when you zoom in.

Chart.js, Apache ECharts, D3 and Recharts are excellent at the sizes most applications need. Below roughly 50,000 points they are genuinely adequate and no vendor should be charging you.

Where we do not win

Static throughput. If your job is to load millions of points once and then pan around them, a purpose-built WebGL engine will beat us, and LightningChart in particular is very good at it. That is a different problem with different tradeoffs, and we are not going to pretend otherwise on a page you can check in a minute.

We also cannot claim to be the only WebAssembly chart. SciChart.js is a C++ engine in WebAssembly too.

What we claim is narrower and, we think, more useful: when the data changes every frame, nothing else we can find comes close, and nobody else even demonstrates the test.

A tell you can check in ten seconds

Open any charting demo with a large, dense, slightly noisy signal. If you see dark gaps in the plotted band, the library is throwing data away before it reaches the screen. Densely plotted data with real variation in it should look solid, not striped.

LightningChart make the same point about their rivals in their own benchmark, footnoting results with "chart library uses down-sampling, the produced data visualization is clearly incorrect".

Do not take our word for it

Every number above came from a demo you can run. Open it, set the point count, start the timer and read your own figures.

1. Run our live demo and note the frames per second at each size.
2. Open any competitor demo and find one that replaces all of its data every frame rather than appending to it. This is the hard part.
3. Compare the point counts, not just the frame rates. A smooth 60 frames per second on 5,000 points is not the same achievement.
4. Watch for the dark gaps.

Point an AI at both and ask it which architecture is doing more work per frame. That is a fair question and we are happy to be judged on it.

Licensing, pricing, deployment, API surface and support are on the JavaScript chart comparison page. How the data reaches the engine without a copy is on the zero-copy data page.