As I’m sure you know, WPF and Silverlight both use XAML as their interface markup language. The idea is that you can define your user interface (UI) and bind it to data without ever writing a line of code (healthy skepticism advised). Whether or not you buy into that vision, the UI possibilities can be stunning, and it seems Microsoft has created a technology that combines both power and flexibility. However, with that power comes responsibility. It’s with an eye on that responsibility that I write this article, in which I want to talk about some of the problems that you can introduce into your application without even realizing it.
Background .NET uses a garbage collector to reclaim and reuse the space left behind when objects are no longer needed. To do this, it builds a list of all objects that are still ultimately referenced from an application root, such as the stack, other objects on the heap, the CPU and statics, to name just a few. Everything else (i.e. objects which have no such references) is assumed to be garbage, and the .NET framework rearranges memory allocation to reuse the gaps these objects filled. A leak (or, if you’re being picky, leak-like behavior) occurs when a section of code fails to release references to objects it has finished working with. The smaller the leak, the greater the number of iterations that must occur before it becomes a noticeable problem. The larger the leak, the more obvious the problem. A really obvious example of this problem is adding an object to a static collection and then forgetting about it. Other common ones involve event handling, which we will discuss later. The simple fact is that if you leave a reference to an object behind, and that reference traces back to an application root, then you have a leak. There are lots of great articles about .NET memory management, and one of the first things you can do to avoid leaks in general is to really understand memory management.
heavyweight User Interfaces in xaml Silverlight and WPF applications are state-full, and allow us to hold state in the form of complex data structures as well as rich UI elements such as images and media. All of this “stuff” adds to the size of the views we create and, ultimately, the size of a memory leak when things go wrong. If you have a memory leak that involves a complex UI then it can quickly become a major problem, especially if users are constantly opening and closing windows as part of standard flows. Read more: simple-talk
QR:
Background .NET uses a garbage collector to reclaim and reuse the space left behind when objects are no longer needed. To do this, it builds a list of all objects that are still ultimately referenced from an application root, such as the stack, other objects on the heap, the CPU and statics, to name just a few. Everything else (i.e. objects which have no such references) is assumed to be garbage, and the .NET framework rearranges memory allocation to reuse the gaps these objects filled. A leak (or, if you’re being picky, leak-like behavior) occurs when a section of code fails to release references to objects it has finished working with. The smaller the leak, the greater the number of iterations that must occur before it becomes a noticeable problem. The larger the leak, the more obvious the problem. A really obvious example of this problem is adding an object to a static collection and then forgetting about it. Other common ones involve event handling, which we will discuss later. The simple fact is that if you leave a reference to an object behind, and that reference traces back to an application root, then you have a leak. There are lots of great articles about .NET memory management, and one of the first things you can do to avoid leaks in general is to really understand memory management.
heavyweight User Interfaces in xaml Silverlight and WPF applications are state-full, and allow us to hold state in the form of complex data structures as well as rich UI elements such as images and media. All of this “stuff” adds to the size of the views we create and, ultimately, the size of a memory leak when things go wrong. If you have a memory leak that involves a complex UI then it can quickly become a major problem, especially if users are constantly opening and closing windows as part of standard flows. Read more: simple-talk
QR:
Posts
0 comments:
Post a Comment