04-27-2021 08:48 - edited 04-27-2021 08:48
04-27-2021 08:48 - edited 04-27-2021 08:48
Has anyone one else noticed that when using document.getElementById across many elements different elements in the SVG, the JS memory just keeps increasing and never returns to the previous level?
I have tried specifically nulling out references used inside functions at the end of the function, which should not be required really as a reference should be garbage collected once the function goes out of scope and the variable is no longer reachable, but still no difference.
I tried declaring a single global variable which is then used inside a function to access an element but it makes no difference.
It seems that no matter what is done, every usage of document.getElementById uses some JS memory which is never returned. I have had it running for hours and can confirm the the memory is never released.
I have also tried refactoring the code to use element.firstChild and element.nextSibling but every usage of those also increases memory used.
Interesting to note that after around 300 elements have been accessed, which happens over the course of 5 mins, the amount of memory used is almost as much as is used if I created a global array up front containing all of the elements that I need by using getElementsByTagName.
I also noticed that the available methods for getting elements is limited:
https://community.fitbit.com/t5/SDK-Development/Get-child-of-DOM-element/td-p/3374037
I was hoping there would be childNodes[] method.
It looks like this an issue with the garbage collection for element references, I have narrowed it down to the line of code which grabs the element and then changes the class and style.opacity of the element, with those lines commented out, the memory usage does not increase.
04-27-2021 13:55
04-27-2021 13:55
Three thoughts:
04-28-2021 08:10
04-28-2021 08:10
Thanks for that info, good to know that I'm not chasing a ghost with the element memory usage.
I have noticed with the garbage collection that it is rather lazy, but I can see memory going down when other references are freed up.
Developers will just have to be aware that the baseline memory usage can't be accurately measured until an app been running along enough since startup to have accessed all of the elements that it ever will. It makes it rather hard to safely work close to the memory limits.