I have demo Asp.net application with Telerik version 2016.2.607.40. Radgrid and Radwindow controls are used.
Issue which I am facing is, when I do action in application, Memory usage increases but not decrease automatically.
I am facing issue in IE11, but working fine in Chorme and Mozilla.
I have already tried DestroyonClose and implemented in demo application.
I am trying to attach demo application but not allowed me to upload(Zip) file.
Please let me know your feedback asap.
5 Answers, 1 is accepted
Hi Brijesh,
Memory management is done by the browser and usually a full postback allows it to unload the page completely and free memory. Iframe elements tend to consume memory and you can easily check that with the following simplicstic code that mimics opening the same RadWindow over and over
<
asp:Button
ID
=
"Button3"
Text
=
"Button2"
runat
=
"server"
OnClientClick
=
"OpenWindow3(); return false;"
/>
<
iframe
src
=
""
id
=
"testFrame"
></
iframe
>
function
OpenWindow3() {
var
iframe = document.getElementById(
"testFrame"
);
var
currDate =
new
Date();
iframe.src =
"Default2.aspx"
+
"?randomVar="
+ currDate.getMilliseconds();
}
What RadWindow's DestroyOnClose feature does is attempt to dispose the content of the iframe in several ways (by removing HTML content, and by removing the iframe from the DOM). It is then up to the browser to free the memory used by the iframe.
You may also find useful the following blog post that has some information on leaks and iframes at the end: http://www.telerik.com/blogs/memory-leaks-and-memory-consumption-in-web-applications-part-2.
You can use the OnClientBeforeClose event to add your own logic that helps. For example, you can try the snippet below.
function
OnClientBeforeCloseHandler(sender, args) {
sender.setUrl(
"about:blank"
);
}
If you do find code that works better than ours (you can download and inspect our source code from your account), please share it with us and we will see how we can incorporate it in the control. In the meantime, you can use it in the OnClientBeforeClose handler.
If you need to contact us directly and send us a sample project, you can do that by opening a formal support ticket.
Regards,
Telerik by Progress
I've the same problem of Brijesh.
I've added the OnClientBeforeClose event on the RadWindowManager and DestroyOnClose="true", but when i open the RadWindow, the memory increases for about 10 mb, after when i close that RadWindow the memory doesn't decrease.
User open some RadWindows in the same page, so the memory after some minutes increases of many mb.
I've used Chrome (71.0.3578.98 version) and Telerik.Web.UI (Q3 2014).
Is there any method to manage/cancel browser's memory usage?
There is no JavaScript code that can invoke garbage collection in the browser. We have added a few lines that may instruct the browser to dispose the contents of the <iframe>, but we do not have control over this. Thus, I don't have anything significant to add to my previous response in this thread.
Perhaps you can consider re-using some RadWindow instances instead of disposing them, as it would reuse the same iframe and perhaps the browser may disposes its memory then. Also, browsers tend to release memory when a full postback happens because that disposes the entire page so you may be able to include one in the workflow you have on that page.
Regards,
Marin Bratanov
Progress Telerik
Hello,
if i set DestroyOnClose property of RadWindowManager to false and i use OnClientBeforeHandler (see your code snippet above), after i open (and close) 10 RadWindow in the same page, the result is: 36MB/47MB (i've used the Memory tool of Chrome - Heap snapshot).
Instead, with DestroyOnClose = true and without OnClientBeforeHandler function, the result is: 106MB/140MB (i've used the same memory tool).
I think to use this method because the result is very good.
Thanks.
Regards.
We can't really control how and when the browser releases memory, though, so for the time being the internal RadWindow code will stay as it is, because it has worked more often than not so far. I am monitoring similar reports and as browsers evolve if it seems that navigating to "about:blank" is consistently better, I will change it. At the moment, though, there is little evidence to support that, in some cases it is better, in others - it is not.
--Marin