Good evening. Lately I’ve been troubleshooting a problem with page memory usage increasing. Over time, the memory grows exponentially and reaches several gigabytes. To explain the problem, we need to describe how we use charts:
On our website in real time, depending on our algorithm, the charts replace each other. The user constantly sees 4 charts, which are constantly replaced by others. Adding new charts occurs unnoticed by the user and only after the graph is fully loaded and drawn does it replace the previous one. That is, the user actually sees 4 charts, but there may be more on the page. After replacing the desired chart, the old one is deleted using surface.delete() and removing all dependencies.
At first, when creating a chart, I used the create() method. After a number of attempts to avoid memory accumulation and re-reading the documentation, I came to the conclusion that it is possible, since all graphs are created using create() – they have a common wasm and since there cannot be a situation in which all charts will be deleted (at least 4 are always present ), then wasm memory is not freed. Tell me if I’m right about this.
Afterwards, I decided to try to create charts using createSingle() with a reliable method, which now, since each graph has its own wasm, memory will be freed. Perhaps this was the case, but I can’t say for sure, because now after some time the page began to reload automatically with the appearance of an error, the screenshot of which I attached. This is most likely due to a wasm limitation on the page when using createSingle. Although it’s strange, when you delete the chart, the amount of wasm should decrease. And even with a limit of 16 copies, this should be enough. Please explain this error to me as well, perhaps the problem with rebooting can be somehow solved by you (I’m not sure that this should happen)
Thank you very much in advance for your answer. Have a good day!
Hi Yevhenni, memory should be reclaimed in both scenarios using create() and createSingle so long as (a) .delete is called and (b) there are no JS memory leaks aka you’re not holding onto sciChartSurface or wasmContext variables globally. Can you provide some code to reproduce this? I’m sure we can solve it for you. Also are you using React? We’re about to publish a scichart-react npm package which will correctly handle chart lifecycle. This would be a good test case for that.
(Admin note): Related question with code to reproduce is now here https://www.scichart.com/questions/js/optimization-problem-1
- You must login to post comments
Without code to reproduce the issue I’m going to share with you our general memory debugging tips.
And this links to our documentation pages on Memory Best Practices.
In short, to delete a chart:
- once you are finished with a chart, call
- delete or remove the
<div/>which the SciChartSurface was hosted in
- ensure all references to
wasmContextare detached (aka don’t keep them in global variables)
This will ensure proper cleanup of memory.
Note: While sciChartSurface.delete() will clear up all its child element memory, if you are frequently modifying elements of the chart e.g. add/remove series, then when a series is removed it also needs to be deleted. There’s a short guide on this here.
Depending on what framework you’re using: React, Angular, Vue or vanilla JS, there may be different ways to achieve this in practice.
For React we have a guide here on creating a Reusable React Component which automatically cleans up memory when a chart is shown/removed. We are also in the process of publishing an open source scichart-react npm package which will do all this for you. Other frameworks (Vue, Angular) may follow depending on user demand.
For further help, send us a code sample and our team will debug it and show you what to do.
Let me know if this helps!
- You must login to post comments