Are there any known memory leaks in the time series chart? We have seen after adding one to our application that the memory usage keeps increasing and eventually the enter Perspective session becomes unusable. Killing chrome and restart appears to resolve the issue.
Is the time series chart using the same amcharts library as the rest of the chart objects?
We haven’t observed any memory leaks yet. The Time Series chart uses the react-timeseries-charts library (specific to time series data) as opposed to the amCharts library. If you’re seeing this happening pretty consistently, would you be willing to share a view that is causing the behavior as well as the version of Ignition and browser you are using?
8.0.10 with Chrome V83. Sorry for all the white out.
One of our engineers was monitoring the heap with Chrome dev tools and found the DOM nodes jumped significantly when navigating to the screen and they don’t appear to drop out.
I can provide a little more information on this issue (same application as above). Leaving the displayed screen open doesn’t appear to cause Chrome’s memory to get too large, but going in and out of the screen (and perhaps other screens) seems to eventually cause the memory to grow very large (over 1.6GB seems to be an issue and we’ve seen it grow over 2.2GB), rendering the application useless until Chrome can be killed and restarted. Therefore this may not be explicitly tied to the Time Series Chart, but considering that is a screen being used a lot that is where people are noticing the major slow down.
I see this bug in 8.0.6. but it seems fixed in 8.0.12 finally.
Please try it in 8.0.12 and tell us if you see this or not.
I will have to wait to try this as 8.0.11+ resulted in poor carousel performance which I need to wait for a resolution on before I can move on from 8.0.10.
I made a handful of updates to the underlying chart library for 8.0.12 that allowed proper propagation of property value changes. For the most part, garbage collection is pretty good with the time series charts. There were some overall performance improvements made in 8.0.12 and 8.0.13 that should result in better browser memory management. This will continue in 8.0.14 as well.
I’ve not had a chance to try the newer versions yet (still on 8.0.10) but just wanted to provide a little more information. It appears the issue gets worse by going in and out of the view with the trend on it. Specifically, what we notice by looking in Chrome Dev Mode is that the DOM Nodes increment up when going in and out of the screen. When the trend is active on the screen the DOM Nodes climb up, then reset back to a lower value. However, when going in and out of the screen the “baseline” DOM Nodes that it resets to end up higher than before. This seems to happen with other views as well, though perhaps not as bad. Sometimes, but not always the JS Heap size will also grow quite large. The end result is that once the overall memory usage by Chrome gets too high the performance is severely degraded and chrome needs to be restarted to work well again.
I was able to upgrade to v 8.0.14 and the problem with Chrome slowing down to a point of being unusable still persists. The hardware being used has 4GB RAM. As I said previously the application becomes pretty slow around 1.6GB or so of usage in Chrome and is definitely an issue above 2GB.
Were you ever able to isolate the issue on your end?
I have a ticket open (work not started) to scrutinize the fork of underlying library that I maintain. There were no major performance concerns found when we picked this library to use as a rendering layer, but I’ve fixed bugs as I’ve found them.
Hello all, I wanted to circle back on this to post my findings after digging into the issue reported here:
TL;DR: No memory leaks were detected in the Time Series Chart or the underlying chart library components. Check any browser add-ons for known memory leaks and update/remove them (you can run a session in an incognito window as well).
Against the latest 8.1.1 codebase, I ran 2 different main tests (as well as multiple small sub tests), each totaling ~3 hours:
line, area, and scatter charts (respectively). The final trend displayed all 6 tag history pens as bar charts. This totaled 12 displaying pens.Baselines and markers were added to each trend.For the duration part of the test, there was no additional JS memory consumption noticed. The JS memory in use remained at ~48MB with small changes accounting for the data being displayed within the chart at the time of the snapshot:
For the momentary memory spike part of the test, there was a stepping-up effect in both DOM node and JS memory heap allocation that did return back to a baseline level once the navigation between pages had stopped and garbage collection had run.
With this test, the data in the chart was not readable, but this was an attempt to cause the error noted in this bug. For the duration part of the test, there was no additional JS memory consumption noticed. The JS memory in use remained at ~75MB with small changes accounting for the data being displayed within the chart at the time of the snapshot:
For the momentary memory spike part of the test, there was a stepping-up effect in both DOM node and JS memory heap allocation that did return back to a baseline level once the navigation between pages had stopped and garbage collection had run. It's worth noting that navigation between views took significantly longer because of the number of DOM nodes being displayed by the chart:
FiberNode). Also a sign that the inner chart components clean themselves up quite efficiently.