FormidableLabs / FormidableLabs/victory

Performance with large data sets

Open
#1,669 11 comments 7 reactions 0 assignees View on GitHub
Issue: Accepted Type: Performance :chart_with_upwards_trend:
Dominant language
TypeScript
Stars
11.2k
Forks
536
PR merge metrics
No merged PRs in 30d

Description

# Bugs and Questions

### Checklist

- [x] This is not a `victory-native` specific issue.

- [x] I have read through the [FAQ](https://formidable.com/open-source/victory/docs/faq) and [Guides](https://formidable.com/open-source/victory/guides/) before asking a question

- [x] I am using the latest version of Victory

- [x] I've searched open issues to make sure I'm not opening a duplicate issue

### The Problem

Want to move from Prometheus to Victory, but Victory charts do not perform well with large data sets.

>For our use case, the point of using large data sets is to see if anything stands out, rather than looking individual lines in a graph. Either too low or too high is what users tend to look for in a graph that has a lot of series.

**Update**: Prometheus appears to generate charts using Rickshaw, which is built on D3.

### Reproduction

https://codesandbox.io/s/victory-perf-issue-vh3kp

In this example, `DATA_SET_COUNT = 150`. The chart tooltip really lags when `DATA_POINTS_PER_SET = 100`. And the browser begins to hang at `DATA_POINTS_PER_SET = 300` or more.

# Feature Requests

### Checklist

- [x] I've read through the [Docs](https://formidable.com/open-source/victory/docs) and [Guides](https://formidable.com/open-source/victory/guides) to make sure this functionality doesn't already exist

- [x] I've searched open issues to make sure I'm not opening a duplicate issue

There is an issue (#655) related to Zoom & brush containers from 2017; however, performance issues can be seen with just a bare bones line chart.

### Description

Victory is based on SVG and renders individual nodes for each data point. However, Prometheus / Rickshaw charts are also based on SVG and have much better performance with large data sets.

For the Prometheus / Rickshaw chart example below, there are a total of 134 time/data series. Each data series has approximately 1800 data points. Despite there being more than 200k data points, there are no performance issues. The Prometheus / Rickshaw chart renders quickly and the tooltip is very responsive.

**Prometheus / Rickshaw chart (200k+ data points)**
![prometheus-chart](https://user-images.githubusercontent.com/17481322/90558310-ddf72a00-e169-11ea-9bf7-24485c0f1e8c.gif)

In comparison, the Victory line chart, from the reproduction codesandbox example, does not perform well with large data sets, despite having far fewer data points than the Prometheus / Rickshaw example.

The chart tooltip really lags when `DATA_POINTS_PER_SET = 100` (see below). And the browser begins to hang at `DATA_POINTS_PER_SET = 300` or more. The timer count at the top demonstrates how much the browser has slowed.

**Victory line chart (15k data points)**
![victory-chart](https://user-images.githubusercontent.com/17481322/90647179-0af91a80-e206-11ea-8157-d801e8e24d29.gif)

**Prometheus / Rickshaw output**
Noticed in the debugger that Prometheus / Rickshaw renders `path` tags without `clip-path` tags, which may contribute to better performance with large data sets?

Screen Shot 2020-08-18 at 2 27 55 PM

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.