This section is very depressing, whether it is the translation process or the content of the article. The differences between such simple operations on DOM can lead to such a large leakage problem. It is true that there is no language. After reading this article, you are welcome to talk about your feelings. My feelings are attached to the end of the article.
Cross-Page Leaks)This leakage problem is often caused by insertion sequence, mainly because the temporary objects in the object creation process are not promptly cleared and released. It generally occurs when a page element is dynamically created and added to the page DOM. The simplest example scenario is to dynamically create two objects and create a temporary domain between the child element and the parent element) it should be the object that manages the hierarchical relationship between elements ). Then, when you add the two parent-child structure elements to the page DOM tree, these two elements will inherit the hierarchical management domain object in the page DOM, and leak the temporary domain object created previously. The following illustration shows two methods to dynamically create and add elements to the DOM of the page. In the first method, we add each child element to its direct parent element, and then add the created entire subtree to the page DOM. When some related conditions are appropriate, this method will cause leakage due to temporary object problems. In the second method, we create dynamic elements from top to bottom and add them to the page DOM structure immediately after they are created. Since each added element inherits the structure domain object in the page DOM, we do not need to create any temporary domain. This is a good way to avoid potential memory leakage.
Figure 3. DOM Insertion Sequence Leakage Model
Next, we will provide a leak example that avoids most of the leak detection algorithms. Because we have not actually leaked any visible elements, and because the leaked object is too small, you may not pay attention to this problem. In order to leak our example, a script function pointer must be included inline In the dynamically created element structure. After we set the relationship between these elements, this will expose the internal temporary script object. Since this leak is small, we have to execute the example thousands of times. In fact, the leakage of an object is only a small number of bytes. After running the sample code and navigating the browser to a blank page, you will see the differences between the two versions of code in memory usage. When we use the first method to add a child element to its parent element and then add the child tree to the page DOM, our memory usage will slightly increase. This is a cross-Navigation leak. Only when we restart the IE process will the leaked memory be released. If you use the second method to add the parent element to the page DOM and then add the child element to the parent element, your memory usage will not increase after running several times, at this time, you will find that you have fixed the problem of cross navigation leakage.
<Html>This type of leakage should be clarified because this solution is contrary to some of our useful experience in IE. Creating DOM elements with Script objects and their associations are key points to understanding this leakage. This is actually crucial for the leakage, because if the DOM elements we create do not contain any Script objects and they are associated in the same way, we will not have any leakage issues. The second technique in the example may be more effective for correlated large sub-tree structures (because in that example we only have two elements in total, therefore, creating a tree structure unrelated to the page DOM does not have any efficiency issues ). The second technique is that no script object is associated at the beginning of element creation, so you can create a subtree safely. When you associate your subtree with the page DOM, you can continue to process the script events you need. Keep in mind and follow the rules for using circular references and closure functions. You will no longer encounter different leaks in your code when mounting events.
I really want to point out this problem, because we can see that not all memory leaks can be easily discovered. They may be trivial issues, but they often need to be executed thousands of times in a smaller leak scenario, just as they are caused by the order of DOM element insertion. If you think you can use the so-called "best" experience for programming, you can rest assured, but this example shows that even the "best" experience may leak. Our solutions here hope to improve these existing good experiences, or introduce some new experiences so that we can avoid the possibility of leakage.
To be continued...
I had to admit that I was confused after carefully completing the content of this section. The so-called Cross-Page Leaks are the most serious memory Leaks in IE. The circular references and closure functions mentioned in the previous two sections can be found and reasonably avoided. Here we will not talk about the number of Cross-Page Leaks scenarios. The DOM insertion sequence in a single example is enough. Because when using Dhtml, you can use a GetXxx, CreateXxx, or GenerateXxx function to obtain a complex Html object structure, and attach it to the required primary DOM is a common operation, now we have to bring Leak, which proves that we can't even trust radish in this year. I have seen a saying that some IE Windows have all (owner) relationships, such as who is who's openner, So IE will maintain some page content for navigate away, to be referenced by other pages. But I don't know how to do it. After the page jumps to another domain or a completely blank (about: blank) page, the occupied memory still cannot be released. For such a serious bug, Microsoft can also name it Cross-Page Leaks. In fact, as long as the navigate to other domain or navigate to blank page can be ensured, the memory will be completely released (GC is not required here, and all the release will be done directly ), other leakage problems are not so acute, because the user still has the opportunity to completely clean up and recycle the memory without shutting down IE. After running for a long time, IE occupies 2, 3, MB of memory (PM + VM), which can be greatly reduced. Another inexplicable problem that cannot recycle memory is that the efficiency of the script engine becomes abnormally low. In other words, the current machines are all M or 1g memory, and IE is occupying 2, 3, M memory, or even 3, 4, M is not an intolerable problem. However, at this time, the script engine does not know how to do this, and the running efficiency becomes very low, it seems that the GC script engine needs to completely sweep and mark the leak memory each time. That price can be imagined. Of course this is a conjecture, otherwise it cannot be explained why the efficiency of the script engine has become so low.Start building with 50+ products and up to 12 months usage for Elastic Compute Service
1 on 1 presale consultation
24/7 Technical Support 6 Free Tickets per Quarter Faster Response
Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.
A comprehensive suite of global cloud computing services to power your business
Payment Methods We Support
