A painting slows down after a while with tons of updates

[Tucsky]

Lightweight Charts Version: 3.7.0 & 3.8.0

Steps/code to reproduce:

• Standard setup with candlestick and volume (don't matter)
• And very very fast realtime update

Actual behavior:

CPU gradually increase (maybe more than it should?)
..then after like 20min CPU shoots up to 100% for no apparent reason

The whole update task takes about 250ms, 90% of it being dedicated to painting the time-axis-widget

This is what the same update looks like at the very beginning (takes about 15ms)

Once cpu goes 100% it doesn't come back. However I have found that changing layout font size fixes it

It's only temporarily tho, the CPU start to increase again and eventually melt up

CodeSandbox/JSFiddle/etc link:

https://jsfiddle.net/qktjy154/5/ - takes about 20min on my build (i7-9700 3.2ghz, 16gb ram), tab needs to remain active

Will update

[Tucsky]

Jsfiddle not good for perf monitoring so I uploaded this http://51.255.41.169/lcissue/test.html
same code as the jsfiddle + measure the execution time of TimeAxisWidget.prototype._internal_paint

The data flow is constant, nothing changes in the way data is added into the chart and about 12min in the load get so heavy almost crash the page

meltdown.mov

The updates are fast af, but the lib should handle it, it did in the previous versions (early in the 3.x for sure)

[timocov]

Hi @Tucsky, thanks for your report! Have you tried to reproduce the same issue in different browsers? Also, is it a type that you stated that there is a possible memory leak but measure CPU usage instead? Quickly looking at your data I can see that for some reason a browser slows down the rendering of the text (you can see that in this code all the library does is call ctx.fillText()).

I just kept the page for several minutes and didn't see any heavy memory usage though, every time I click on "Collect garbage" button it goes down for the same value (around 5-6mb in my case). Also the execution time is the same (less than 1ms).

[timocov]

@Tucsky are you able to reproduce it in different browsers/PCs?

[Tucsky]

Yes you are right, memory is not the issue it's the CPU, I was looking for an equivalent term but didn't find any 🙂 it's about the Time Axis canvas operations (fillrect, filltext etc) taking 100x longer than it should after some time. The time before it 'triggers' is relative to the amount of updates made per sec, and most likely the power of your own cpu. I have the full runtime performance snapshot of it if needed (about 20s before the heavy load starts to manifest and a few sec in). will try on other browsers asap

[Tucsky]

@timocov I can absolutely reproduce the issue on my 15" 2015 macbook pro

takes about the same time to trigger

[Tucsky]

Oneplus 5

[Tucsky]

No issue on firefox 🥇

[timocov]

No issue on firefox 🥇

What version of Chrome do you use on your laptop and phone? It looks like the issue of the browser for now.

[Tucsky]

@timocov I'm using 96.0.4664.110 (last version) on both

[timocov]

@Tucsky could report this to Chromium please? I just tried to reproduce it on Version 88.0.4298.0 (Developer Build) (64-bit) and it works fine (at least for 16 minutes). I'm able to reproduce it with the latest Chrome version so most likely it's Chromium's issue. Afaik they made some changes related to this recently so probably it's related.

Also, as soon as you're unable to reproduce it in FF it only confirms that it's issue in Chrome. You can also check in Safari, but I believe you won't be able to reproduce it.

[timocov]

Hey @Tucsky, did you file an issue in Chromium by any chance for this issue?

[Tucsky]

No I did not, I am unable to reproduce the issue outside of this library
It works just fine when I change the layout fontSize every couple minutes so I'm just doing that now

[timocov]

Got it, thanks! We'll report to Chromium this issue then. It seems that it might be caused by some other scenarios and your repro is simple enough. I'll post a link here once it will be created.

[timocov]

It seems that @kirchet found the cause of the issue. We'll provide a fix soon.