Setting innerHTML increases the number of HTML nodes

Explain the problem

So, I noticed that when using someElement.innerHTML number of DOM nodes increases.

enter image description here

I assume the link is dead, but the memory is still allocated until the garbage collector deletes the object.


Example (HTML):

  <html> <head> <meta charset="utf-8"> <link rel="stylesheet" href="test.css"> <script src="script.js"></script> </head> <body onload="startTimer()"> <div id="timeContainer">Time Goes Here</div> </body> </html> 

Example (JavaScript):

  var timer; var body; var oldTime = ""; var timeContainer; function startTimer(){ timeContainer = document.getElementById("timeContainer"); timer = setInterval(getTime, 10); } function getTime(){ var d = new Date(); var timeString = d.getUTCHours() +":"+ d.getUTCMinutes(); +":"+ d.getUTCSeconds(); if(timeString != oldTime){ oldTime = timeString; timeContainer.innerHTML = timeString; } } 

What I tried so far

  • I tried using someElement.textContent .
  • I deleted whoe ParentElement every time it updates the timer and creates a new one.

Question

How can I avoid increasing the number of node even once, when I just update the content and why does it need an additional node?

+7
javascript html
source share
2 answers

I assume the link is dead, but memory is still allocated until the garbage collector deletes the object.

Correctly.

How can I avoid increasing the number of node even once when they just have refreshing content?

You cannot and should not worry about it. This is the browser domain, it does what it wants to do when it comes to garbage collection (and different browsers can do it differently).

I deleted the whole ParentElement every time it updates the timer and created a new one

Just because you deleted it (made it inaccessible) does not mean that it was garbage collected instantly.

+2
source share

This is natural and expected.

Browser garbage collection starts asynchronously. Once your actual DOM disconnected the nodes, it does not guarantee that they are heap free. They will remain there until the next garbage collection trigger.

As dev tools # Fix Memory Problems said , don't worry about it and leave it in the garbage collection process.

Please note that leave it in the GC until it affects the performance of your applications. If this really pushes you to a slow browser and hang up the mess, you should really start to profile it and fix it. This could be a potential memory leak.

A DOM node can only be collected by garbage collection, if there are no links to it from the DOM tree of the page or from JavaScript code. A node is called "detached" when it is removed from the DOM tree, but some JavaScript still references it. Individual DOM nodes are a common cause of memory leaks. This section describes how to use DevTools heap profilers to identify individual nodes.

And the fix is ​​provided in the same article using Chrome Dev tools. In short, take pictures of your heap and start looking at individual nodes.

enter image description here

The nodes highlighted in yellow have direct links to them from JavaScript code. Nodes highlighted in red do not have direct links. They are alive only because they are part of the yellow tree node. In general, you want to focus on the yellow nodes. Correct your code so that the yellow node is not alive longer than it should be, and you also get rid of the red nodes that are part of the yellow node tree.

Read more ..

+2
source share

All Articles