the-hideout
Memory leak on map pages
Describe the Issue
I usually don't close the tab with map on tarkov.dev. But after some time in background i see high memory consumption. Last time it was whopping 3.7 gig.
Checking ram usage on tab hover in latest Chrome. But same info visible in Chrome task manager (both pics included below). Entire console output pasted too.
It doesn't consume as much at freshly opened tab ~200-300mb as any other page on site. Reload doesnt free memory, only close-reopen does(or browser restart). ctrl+R or ctrl+shift+R doesn't help either.
Im seeing that behavior for many months.
Expected Behavior
Map tab in background doesn't increase in memory consumption on idle after page fully loaded.
To Reproduce
Open any map and let it sit for a day > see ram high RAM usage
Client
Desktop
Browser
Chrome
Relevant Console Log Output
Entire console output doesn't fit so here is a link.
https://pastebin.com/XCcrhzMa
Extra Information
I've noticed similar behavior as well. Not really sure where to start troubleshooting it, but I suspect it has something to do with the way we're implementing Leaflet in React.
@Razzmatazzz
Could be an issue with the useEffect-Hook, which re-executes the whole map rendering logic on each dependency update. Already noticed that issue too, because the Map gets rendered like 6 times on initialization. Added to that, some dependency changes trigger re-renders of the map during the runtime.
Since im not an react expert but mainly using Angular and RXJS in my projects, isn't there a better way to handle the map logic only once while utilizing stores or something like that, ensuring that async data is loaded to then fire the render cycle of the map? This would improve performance, would prevent unnecessary rerenders and could fix memory leaks.
@HoodOG1 that's a good point and a decent place to start. I'm far from a React expert myself; I've only learned it in bits and pieces from helping to maintain this repository (and the repo it was forked from). I'm sure we could get it running much more efficiently with some refactoring.
This is a really interesting issue, and a VERY good find, so thanks @Neoniq !
If anyone does take this up, I'd be very interested to see what the cause and solution is
This may be resolved by #1093 . It's deploying now, so it would be helpful if folks could refresh the page and test to see how it's working.