search

runziggurat / ziggurat-viz

The Ziggurat Visualizations.
https://app.runziggurat.com
1 stars 0 forks source link

Memory leak in force graph. #37

Closed muzam1l closed 1 year ago

muzam1l commented 1 year ago

This can be easily verified by checking fps on the Geo graph. It is usually 60fps after the page refresh and decreases on the force page visits.

Steps to reproduce:

1) Go to geo graph, do a page reload and note down the fps. 2) Navigate to the force graph, then switch to geo tab from the Navbar, FPS decreases. 3) Repeat the 2) to see fps decreases even further.

It could also be verified by watching the js heap memory, which keeps on growing, when switching between force and other tabs.

The above behavior does not exist when switching between geo and home pages.

muzam1l commented 1 year ago

The current workaround is to just refresh the geo page! If we can't cleanup force graph resources in destroyForceGraph, we may then just automaically reload the pages when navigating. It would definitely be slow, as it has to reload the entire app. Any ideas @kylegranger?

kylegranger commented 1 year ago

@muzam1l Hmm, I can't think of anything at the moment that might help, and I assume you've tried the usual things to fix it. You could check the force-graph repository, try the various demos in the readme. Do you see a memory leak there? https://github.com/vasturiano/force-graph

muzam1l commented 1 year ago

I did try setting empty node state after the unmount. That did help a little bit, but the issue is still there.

Their examples do not mount and unmount as we do on page transitions. They just render and it stays as long as page is open.

kylegranger commented 1 year ago

It might then be an issue with Three.js, or maybe the WebGL context not getting freed. It is an interesting data point that you don't see this behavior with the geo renderer.

muzam1l commented 1 year ago

Seems to be fixed now 🙂, somehow 😅.