Public comparison of LightningChart® JS performance against other JavaScript charting libraries in visualizing different Heat map charts.
UPDATE 1.12.2021: Updated performance comparison with LightningChart JS version 3.3 once again completely changes the previous results.
A separate section has been added to show the progression of LightningChart JS heatmaps performance with time. Click here to jump to it.
UPDATE 3.9.2021: Updated performance comparison with LightningChart JS version 3.1 completely overthrows the previous results.
Click here to skip to the results analysis.
Heat maps are used for visualization of 3 dimensional data by mapping two dimensions to X and Y location and coloring the location based on the 3rd data dimension.
There are several different sub groups within heat maps in data visualization, this comparison focuses to 2D grid heat maps.
Furthermore, 2D grid heat maps can be categorized into at least 3 types based on the application:
- Static heat map. A data set is loaded and rendered as heatmap based on a color look-up table.
- Refreshing heat map. In this case, the data is dynamic changing every so often (refresh rate). Used in weather data visualization, for example.
refreshing-heatmap.mp4
- Appending heat map. Also dynamic data, but in this case the previous data is not cleared, instead just shifted out as new data is pushed in. Used in audio monitoring and analysis (spectrograms), for example.
appending-heatmap.mp4
This repository tests JavaScript charts performance in all these different applications.
The following chart libraries are included:
- LightningChart® JS v.3.3
- LightningChart® JS v.3.1
- LightningChart® JS v.3.0
- Highcharts v.9.1.0
- ECharts v.5
- ZingChart v.2.9.3
- SciChart JS v.1.4.1633
Competitor results are kept unidentified (for example, "Competitor A").
All referenced benchmark applications are included in this repository.
Benchmark information:
- Date: 03.09.2021
- OS: Windows 10
- CPU: Ryzen 9 5900X
- GPU: RTX 3080
- RAM: 32 GB
- Browser: Chrome & Firefox (better score is displayed)
JavaScript chart performance in heat map application is measured by gathering different performance metrics from a collection of tested heat map dimensions.
Heatmap dimensions are specified by the number of columns and rows, for example "100x100" (10 000 data points).
JavaScript chart performance in static heat map application is measured by following metrics:
- Does the chart render? If not, then the test is considered a failure.
- Load-up speed. This is the time (seconds) from initiating the chart to when the heat map chart becomes fully visible to the client.
The following chart is a visualization of the static heat map benchmark results.
Along X Axis the different tests (increasing data amount) are depicted.
Y Axis corresponds to the load-up speed measurement, higher Y location means faster and thus better result. Line not appearing means that the test failed.
The range of drawn line along X Axis defines the valid range of static heat map data amount which the JavaScript chart library is capable of loading fast. For example, LightningChart JS v.3.3 is capable of loading a 35000x35000 heat map in 7.5 seconds.
JavaScript chart performance in dynamic heat map applications is measured by following metrics:
- Frames per second (FPS). How many times the data set is refreshed per second (average). Values are generally between 0 and 60, where below 10 shows as visibly bad performance.
- CPU usage (%). Browser main thread CPU usage. Large values (> 50%) correspond to heavy power usage and less processing power for rest of the web page. When CPU usage is near 100% the web page performance and interactivity starts to plummet.
- Maximum heat map data amount. This is derived from FPS, it is the maximum data amount which can be maintained with > 10 FPS.
The following charts visualize the performance of different libraries in increasingly heavy real-time heat map applications.
The last bar chart indicates the Maximum heat map size where the library could function with satisfactory performance. For example, LightningChart JS v.3.3 performed well until 6000x6000 (refresh) and 14000x14000 (append).
Refreshing heat map results:
In these tests, all visible heat map data is updated as fast as possible.
Appending heat map results:
In these tests, live data is streamed into the heat map and displayed as fast as possible. 1 column is added between every refresh.
With small heat map sizes (< 10000 total data samples) there is little variation in load-up speed.
However, after 500x500 threshold is passed the difference in hardware accelerated libraries speed is clear, being ready on average ~10x faster than the other JavaScript chart libraries.
Going further, all other competitors drop off as they can no longer handle the extreme amounts of data, leaving only LightningChart JS v.3.3 steadily scaling upwards.
In 5 seconds, LightningChart JS v.3.3 can display a 30000x30000 heat map with a whopping 900 million data points. This is 2000 times more data than the average competitor without hardware acceleration, and 100 times more data than the closest hardware accelerated competitor. The maximum confirmed heat map that LightningChart JS v.3.3 can display with 64 GB RAM is 5.6 billion data points.
| Web chart | Heat map size (less than 5 seconds load time) | Data points |
|---|---|---|
| LightningChart JS v.3.3.0 | 30000x30000 | 900 million |
| Competitor D | 3000x3000 | 9 million |
| Competitor B | 1000x1000 | 1 million |
| Competitor A | 500x500 | 250 thousand |
| Competitor C | 200x200 | 40 thousand |
The available heat map dimensions range is crucial in real-life applications, because if it is not enough it means you have to down-sample your data which results in precision loss! This can be a show stopper in many cases.
Another factor that is not visible in these benchmarks is the performance of cursor, panning and zooming interactions. While they can not be taken for granted in just any web chart, this short clip shows how heat map size does not affect the quality of LightningChart JS interactions.
extreme.heatmap.interactions.mp4
With refreshing and appending heat map applications it is clear that charts without hardware acceleration can't function when heat map size exceeds even as little as 50x50;
These libraries FPS quickly plummets to 5-15 range and even with 25x25 heat map (125 total data samples) they use 100% of available CPU power. In practice this would mean that nothing else on the web page could do anything interactively.
In refreshing stress tests, it becomes apparent that even other hardware accelerated charts can't keep up, performing on average ~6.5 times slower and finally crashing as the heat map size exceeds 3000x3000. Lightning Chart JS persists all the way to 14000x14000 heat maps and further without crashing. With 7000x7000 heat map, LightningChart JS performs with a stable refresh rate of ~10.0 times per second. The amount of data processed every second in this scenario is 490 million data points. This is the largest existing data process rate that we have ever proved in a web application. To put it into perspective, in this case the chart is receiving data at a rate equal to 490 000 data sources with 1 kHz sample rate.
| Web chart | Heat map size (refresh rate > 10) | Data points per refresh |
|---|---|---|
| LightningChart JS v.3.3.0 | 7000x7000 | 49 million |
| Competitor D | 1000x1000 | 1 million |
| Competitor B | 100x100 | 10 thousand |
| Competitor A | 50x50 | 2 500 |
| Competitor C | 50x50 | 2 500 |
However, what really makes LightningChart JS shine above the other charts is the appending stress test;
From the results, we can see that LightningChart JS is able to take performance advantage of the fact that with appending heat maps the entire previous data set does not need to be updated - while the closest hardware accelerated competitor drops at around 1000x1000, LightningChart JS is seemingly unaffected by the increasing data amounts and still performs with 140 FPS with a 35000x35000 heat map (1.2 BILLION visible data points!!). This measurement was completed on Mozilla FireFox, which doesn't allow monitoring CPU usage (unlike Google Chrome), so the CPU usage measurements are missing.
The CPU efficiency of LightningChart in appending heat map applications is mind-blowing - looking at the 12000x12000 test, LightningChart JS only uses 13% of CPU power, which is less than what other solutions require with miniscule 25x25 heat maps. The CPU usage measurement is perhaps the most important performance attribute because it directly translates to the rest of the web page and end user experience – as a rule of thumb, if your chart uses more than 90% of CPU resource then your web page cannot maintain any other form of interactive user interface.
The sheer difference in performance in this test scenario is insane; if we linearly compare data amount and FPS, LightningChart JS is over million times more efficient than the average chart without hardware acceleration, and 35000x more efficient than the closest hardware accelerated competitor.
| Web chart | Heat map size | FPS |
|---|---|---|
| LightningChart JS v.3.3.0 | 35000x35000 | 140.0 |
| Competitor A | 750x750 | 0.2 |
| Competitor B | 1000x1000 | 0.2 |
| Competitor C | 50x50 | 44.0 |
| Competitor D | 4000x4000 | 0.3 |
To see these next generation heat maps in action, head on over to our heat maps examples gallery.
Every time we make significant improvements in LightningChart JS heatmap routines, we make sure to publish the latest results here. This is currently the 3rd iteration of heat maps performance comparison, so we thought it would make sense to add a separate section to focus only on LightningChart and display how its performance evolves over time.
It seems that the speed of loading static heat maps as well as the achievable data capacity has shown the greatest evolution. Following is a depiction of the heat map size that can be loaded in less than 5 seconds.
| LCJS version | Heat map size (less than 5 seconds load time) |
|---|---|
| v.3.0 | 2000x2000 |
| v.3.1 | 13000x13000 |
| v.3.3 | 30000x30000 |
The efficiency of refreshing heatmap has also improved significantly.
| LCJS version | Heat map size | FPS | CPU % |
|---|---|---|---|
| v.3.0 | 1000x1000 | 10.0 | 100.0 |
| v.3.1 | 1000x1000 | 80.0 | 100.0 |
| v.3.3 | 1000x1000 | 164.0 | 48.0 |
And finally, the efficiency of appending heatmap. Similarly to the static heat map progression, this scenario has also evolved significantly across the versions.
| LCJS version | Heat map size | FPS |
|---|---|---|
| v.3.0 | 1000x1000 | 10.0 |
| v.3.1 | 15000x15000 | 130.0 |
| v.3.3 | 35000x35000 | 140.0 |
Something which might not be obvious is that all LightningChart JS development happens because of an identified user requirement. We hope that by writing about performance progression we highlight our ability to evolve together with our users!
Read more about Lightning Chart JS performance why and how at our web site.
The benchmark applications and all related resources can be found in bench/ folder.
Hosting development server
npm i --global http-server
http-server
Afterwards, benchmark index page can be found in localhost:8080/bench by typing the URL directly into a browser (like Google Chrome).
The test parameters are configured by modifying bench/config.iife.js. After modifications, a cache refresh is usually required (reload page with Shift+Ctrl+R).
FPS and Load-up speed metrics are measured programmatically and logged to console.
CPU usage has to be manually monitored using browser developer tools.
SciChart JS requires locally installed license verification software and an active license!