DevExpress XAF is a framework for .NET and Visual Studio developers who wants to create Office-like LOB apps for desktop, web and mobile faster and without hiring a large team.
Friday, July 26, 2013
About profiling memory leaks...
I want to pay your attention to this Support Center ticket, because here I was involved in memory profiling with my colleague, and also because I remember that some time ago somebody from the XAF community asked to elaborate more on the memory profiling process.
I doubt this info will be interesting for experienced developers, but we should not forget that there is a large number of people who are using XAF and who love it because it helps them to care less about the underlying technology and what happens behind the scenes.
Hence, my colleague and I wrote a detailed explanation of how we profiled a case when a report preview window is opened and then closed. So, let me quote us from that ticket:
"In fact, it is not guaranteed that the CG will be called automatically after a period of time.
During the normal application life cycle, GC may not be called at all, unless its garbage collection is forced by the CLR.
You can learn more on how the GC works at http://msdn.microsoft.com/en-us/library/ee787088.aspx#conditions_for_a_garbage_collection.
Now please let me elaborate on how we find memory leaks in .NET apps internally.
For example, you may want to check for memory leaks when a report preview is shown.
Here are the steps you would perform:
1) Run the application under the profiler and open the report preview;
2) Close the report preview;
3) Now we will make a single snapshot. Take note that we did not make a snapshot before the report preview was closed, because at this stage not all static variables and other resources can be loaded and properly initialized;
4) Open the report preview once again;
5) Close the report preview;
6) Make the second snapshot.
You can learn more about these steps in the documentation of your preferred memory profiler. For instance, we can also use the .NET Memory Profiler:
http://memprofiler.com/OnlineDocs/default.htm?turl=findmemoryleaks.htm.
At this stage we can analyze the difference between these two snapshots to see whether there are any memory leaks.
In particular, we are looking at the following columns:
1) Column Live bytes / Delta
2) Column Live instances / Delta
Refer to the http://memprofiler.com/OnlineDocs/default.htm?turl=overviewpage.htm help article for more details.
As for the Real-Time Page, it only provides auxiliary or supporting information, and does not allow you to determine a memory leak:
http://memprofiler.com/OnlineDocs/default.htm?turl=realtimepage.htm."
Of course, tools like .NET Memory Profiler are themselves extremely helpful as they guide you through the process. For instance, take a look at the Tasks window in this tool:
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment