Chart.js

Chart.js copied to clipboard

Expected behavior

I have a site that shows various graphs of Covid-19 spread in different countries and regions, at https://mackuba.eu/corona/, which uses Chart.js. I've been maintaining it since March 2020, and at the beginning the charts worked fine since there wasn't much data to show, but the datasets were getting longer and longer, and last year already it was working kind of slow. It's especially bad in Chrome and Firefox, surprisingly it's much better in Safari.

I've built it in Chart.js 2.x, since 3.0 only came out last year. I read that 3.x includes some performance improvements, so I thought it would fix the problem.

I struggled for some time with an issue with TypeScript definitions, which changed in 3.x, but I couldn't figure it out and in the end I worked around it by marking all Chart.js types as any.

I managed to update all the calls to Chart.js to the 3.x API and started testing the site. The result was… unexpected. The site seems to work just as slow in Chrome, but now it also works slower in Safari…

I've managed to extract a minimal code sample that shows the issue to a new repo: https://github.com/mackuba/chart_slow_demo. It's a bit of an extreme example, because it shows 20 datasets with the full date range (since March 2020), and normally there's a few up to 10 datasets and a smaller date range - but this way the problem is more obvious. You can make the chart "lighter" by removing some items from the population dictionary.

Current behavior

In Chrome (Brave):

• chartjs2.html (2.9.3): works slow (animation starts quickly but is like 3 fps)
• chartjs3.html (3.7.0): slow, but in a different way (for more than half a second nothing is happening)

In Safari:

• chartjs2.html (2.9.3): works ok - animation starts immediately and is faster than in Chrome
• chartjs3.html (3.7.0): there's almost a second of delay before the chart starts animating

I'm testing this on 2018 MacBook Pro (macOS 11.6.2) - if you're checking it on a fast computer like M1 Macs and it loads immediately, try on an older machine.

Safari version: Version 14.1.2 Brave version: Version 1.34.80 Chromium: 97.0.4692.71 (Official Build) (x86_64)

Reproducible sample

https://github.com/mackuba/chart_slow_demo

Optional extra steps/info to reproduce

No response

Possible solution

No response

Context

No response

chart.js version

v3.7.0

Browser name and version

Safari 14.1.2

Link to your project

No response

I'm not sure if this will display - I made a video that shows the difference, first v. 2.9 and then 3.7:

https://user-images.githubusercontent.com/28465/149399803-79a1c328-dfd1-4ac4-9b27-104c2aa9a19d.mp4

There are a few things that you can use to improve speed.

1. disable points, only draw the line. (pointRadius: 0)
2. switch to time scale
3. convert data to {x: timestamp, y: value} format. set parsing: false. don't need the nulls anymore, so remove those.
4. disable animation

I played around with your sample repo a bit, did steps 1 and 2 + tested zoom plugin. You can see my tests here: https://github.com/kurkle/chart_slow_demo

Hey,

thanks for the ideas - I'm doing some experiments with this, I'll see if anything helps.

@kurkle Ok, here's what I'm seeing:

1. Disabling animation:

   • obviously, much faster in Safari - but visually this isn't as nice, of course
   • about as fast on v3 as on v2 - which would imply the 3.x slowdown is in the animations area
   • Chrome still takes about ~1s before it starts to react

2. Disabling points:

   • more fluent animation in Safari (v2) - although it obviously looks different, I need to think if I want it this way
   • even with no points, there is still a ~1s delay in v3 in Safari (!) and then it animates fluently once it's finished the work
   • Chrome works much faster without points (but still a delay in v3)

3. Time scale:

   • no noticeable difference

4. Time scale with data objects:

   • there is a slightly shorter delay in v3, but still slower than v2

Does it make sense to even try data objects {x,y} without a time scale? (I don't even know how to do that, the line doesn't render properly)

So my conclusions for now are:

• there's probably no point disabling animations, since it doesn't really help Chrome and Safari works pretty fine as is
• I will consider disabling points, even if only in Chrome and keep them in Safari
• I'm staying on v. 2.x for now, since 3.x is slower in most configurations except if I disable animations (in which case it's about the same)
• I will also try some of the things here: https://www.chartjs.org/docs/2.9.4/general/performance.html

As for the v3 slowness, it seems to me that it's something about… pre-calculating animations? Because the delay (which isn't visible in v2) goes away if I disable animations, but it happens before the animations start visually happening (for ~1s after you click the checkbox nothing happens, even the checkbox doesn't get un-clicked and the chart is static, and only a moment later it animates; this happens even with points off, in which case the chart animates pretty fluently in Safari after that delay).

Following this issue. I am seeing similar performance problems. My application is a set of dashboards with charts. As I move from one dashboard to another and back, each render takes 1 second longer and keeps accumulating as I go back and forth. It feels almost like a memory leak type of issue where prior data applied to a chart isn't cleaned up prior to rendering the new data set.

I'm experiencing the same issue as OP. Applied the recommendations from https://www.chartjs.org/docs/3.8.0/general/performance.html without significant improvements unless I disable animations (which is not an option in my context)

Seeing significant performance issues between 3.X and 2.9.3. This is to the point that the browser renderer process will lock up given enough time.

Has there been any headway on this? In testing these issues continue even with the latest release. 😞

@LeeLenaleee you closed the related ticket above as not planned?

Closed it because it's a duplicate

I just want to add my concern about performance, as mentioned in https://github.com/chartjs/Chart.js/issues/10637 as well. I have recently upgraded from chartjs 2.9.3 to 4.1.1.

Unfortunately, the 'performance' problem is impacting other things very negatively. Note that the charts themselves appear to be performing fine - I can interact with them without problems.

Apart from the charts, I have other elements on my dashboard page, including bootstrap collapse sections, items that have tooltips and can be interacted with and clicked on.

On chartjs 2.9.3, the dashboard page was performing fine. I can hover on elements, click them, and the page responds almost instantly. After the upgrade, all the other elements on my page have become laggy and slow to respond to clicks. It takes a frustratingly obvious 2-3 seconds to interact with anything.

If I hide/remove all the charts, the performance improves again, back to how it was with 2.9.3. Reverting back to 2.9.3 seems to be the only solution at this stage.

I hope someone has some clues as to why the chart performance has dropped so rapidly! Even disabling chart animations did nothing to improve my page performance.

I tried recording using the performance monitor in chrome for more details. Miraculously, while the recording is taking place, the issue goes away! My page performance returns to normal. As soon as the recording is stopped, it returns to the choppy performance.

My project is using angular 14, and my suspicion is that the chartjs 4.1.1 is messing with the angular rendering pipeline, causing all my other elements to be reevaulated slowly and costing page performance on any dom interaction (via angular).

Does anyone have any comment or suggestions as to why this might be the case?

I have inspected and compared 2.9.3 vs 4.1.1 in the dom, and I noticed that the new version is missing something called a chartjs-render-monitor and chartjs-size-monitor. Could this be a clue? Or is there something else in the canvas that is interfering and causing issues for frameworks (like angular, in my case).

@naviln maybe some issue in resizing? Try responsive: false in the charts options, does it make a difference?

@naviln maybe some issue in resizing? Try responsive: false in the charts options, does it make a difference?

Thanks for the response @kurkle. I've tried setting options.responsive to false, but the same problem remains.

Any other ideas or options?

Any other ideas or options?

No other ideas, would need a reproduction to find out the cause.

Hi, we also have a performance regression issue when migrating from 2.x.x to 4.x.x. Here is a diff when calling chart.update() on a line chart.

With 2.x.x, it takes 180ms :

With 4.x.x, it takes 855ms :

Both contains 29 lines with 336 points. On the update we are changing the colors of the lines.

Hi, we also have a performance regression issue when migrating from 2.x.x to 4.x.x. Here is a diff when calling chart.update() on a line chart.

With 2.x.x, it takes 180ms :

With 4.x.x, it takes 855ms :

Both contains 29 lines with 336 points. On the update we are changing the colors of the lines.

@bertrandp have you solved your problem? I am exactly in the same situation 😩

@bertrandp have you solved your problem? I am exactly in the same situation 😩

No. Currently we have both versions in our app (v2 and v4) because in some place the regression is too important, this is annoying. @virtualmartire can you open a new issue and mention my previous message ? Maybe it will be more visible ...

No. Currently we have both versions in our app (v2 and v4) because in some place the regression is too important, this is annoying. @virtualmartire can you open a new issue and mention my previous message ? Maybe it will be more visible ...

Sorry but I don't have the time to prepare all the documentation they request for a simple issue :(