MSDN Magazine - January 2009 - (Page 18)

mouse clicks and will not see tens, hundreds, or even thousands of interop transitions causing delays to their users. That said, when you do take a look at the performance of your interop solution, you should have two goals in mind: reducing the number of interop transitions you make and reducing the amount of data passed on each transition. A given interop transition with a given amount of data crossing between the managed and native world is basically going to have a fixed cost. This fixed cost will be different depending upon your choice of interop technology, but if you made that choice because you needed the features of that technology, then you won’t Your interop solution should help reduce the number of interop transitions you make. be able to change it. This means your focus should be reducing the chattiness of the boundary and then reducing the amount of data crossing it. How you accomplish this depends largely upon your application. But a common, and adaptable, strategy with which many have been successful is to move the isolation boundary by writing a bit of code on the side of the boundary that defined the busy and data-heavy interface. The basic idea is to write an abstraction layer that batches calls into the very busy interface or, even better, to move the portion of your application logic that needs to interact with this API across the boundary and only pass inputs and results across the boundary. Lifetime Management The differences in lifetime management between the managed and native worlds is often one of the biggest challenges for interop customers. The fundamental difference between the garbage collection-based system in the .NET Framework and the manual and deterministic system in the native world can often manifest itself in surprising ways that can be difficult to diagnose. The first problem you might notice in an interop solution is the lengthy amount of time some managed objects hold on to their native resources even after the managed world is finished using them. This often causes problems when the native resource is very scarce and depends upon being released as soon as its callers are finished using it (database connections are a great example of this). When these resources are not scarce, you can simply rely on the garbage collector calling an object’s finalizer and letting that finalizer release the native resources (either implicitly or explicitly). When resources are scarce, the managed dispose pattern can be very useful. Instead of exposing native objects directly to managed code, you should put at least a thin wrapper around them that implements IDisposable and follows the standard dispose pattern. This way, if you find resource exhaustion to be a problem, you can ex18 msdn magazine plicitly dispose of these objects in your managed code and release the resources as soon as you’re done with them. The second lifetime management problem that commonly impacts applications is one that developers often perceive as a stubborn garbage collection: their memory use keeps rising, but for some reason the garbage collector is running infrequently and objects are kept alive. Often they will keep adding calls to GC.Collect to force the issue. The root of this problem is usually that there are a lot of very small managed objects that hold onto, and keep alive, very large native data structures. What happens is that the garbage collector is self-tuning and tries to avoid wasting time doing unnecessary or unhelpful collections. And, in addition to looking at the current memory pressure of the process, it looks at how much memory each garbage collection frees when deciding whether to do another one. When it runs in this scenario, though, it sees that each collection only frees a small amount of memory (remember it only knows about how much managed memory is freed) and doesn’t realize that freeing those small objects can significantly decrease overall pressure. This leads to a situation where fewer and fewer collections happen even as memory use keeps increasing. The solution to this problem is to give hints to the garbage collector as to the real memory cost of each of these small managed wrappers over the native resources. We added a pair of APIs in the .NET Framework 2.0 that allow you to do just that. You can use the same type of wrappers you used to add the dispose patterns to scarce resources but repurpose them to provide hints to the garbage collector instead of explicitly having to free the resources yourself. In the constructor for this object you simply call the method GC.AddMemoryPressure and pass in the approximate cost in native memory of the native object. You can then call GC.RemoveMemoryPressure in the object’s finalizer method. This pair of calls will help the garbage collector understand the true cost of these objects and the real memory freed when releasing them. Note that it is important to make sure you perfectly balance your calls to Add/RemoveMemoryPressure. The third common disconnect in lifetime management between the managed and native worlds is not so much about the management of individual resources or objects but rather of whole assemblies or libraries. Native libraries can be easily unloaded when an application is done with them, but managed libraries cannot be unloaded on their own. Instead, the CLR has isolation units called AppDomains that can be individually unloaded and will clean up all assemblies, objects, and even threads running in that domain when unloaded. If you are building a native application and are accustomed to unloading your add-ins when you are done with them, you’ll find that using different AppDomains for each of your managed add-ins will give you the same flexibility you had in unloading individual native libraries.  Jesse Kaplan currently is the Program Manager of Managed/Native Interoperability for the CLR team at Microsoft. His past responsibilities include compatibility and extensibility. ClR Inside Out

Table of Contents Feed for the Digital Edition of MSDN Magazine - January 2009

Toolbox CLR Inside Out Basic Instincts Cutting Edge Test Run First Look� Geneva Framework Silverlight Windows Mobile Service Station Security Briefs Extreme ASP.NET Foundations .NET Matters { End Bracket }

MSDN Magazine - January 2009

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.