Interop working set


So I promised awhile back to get some performance numbers on hwnd integration. I started with a very simple MFC application (which doesn’t do a whole lot besides use MDI and document-view), and measured the working set of that. Then I recompiled using /clr (best practice is to use /clr only on those C++ files which actually need it, but since this one is fairly small I /clr’ed everything). Finally, I used HwndSource to put some xaml inside one of the MFC CViews. The numbers were:











































































MFC only


with /clr


with WPF


working set total


4744


9224


22956



private


576


1576


5536



shareable


512


844


7356



shared


3656


6804


10064


modules total


2948


6476


16808



WPF




6184



CLR



3288


5980



other


2948


3188


4644


Data total


1700


2584


5640



heap


184


432


2054



gc heap



0


646


Performance numbers always require some interpretation, and these are no different. First thing to note is that your mileage may vary — you aren’t writing the same program I am, and your program may use more or different functionality. (and in that “/clr” column, it’s hard to use less of the CLR than that)  The “modules” and “data” numbers are really there to emphasize that point and to help you map results to your application — eg, # of bytes used by the CLR varies considerably depending on whether you are using just a tiny bit of managed code (the middle column) or more substantial amounts of managed code (column on the right).


The second thing to call out is that there is no one bottom line, although if you had to pick one, it’s probably private working set — bytes not shared or potentially shared with other processes. In WPF, we pay attention to all of those working set numbers, but concentrate the most on private working set as that has the most direct impact on paging.


Final thing to call out is that these are pre-release WPF bits, we’re continuing to make perf improvements and we get a noticeable boost just by doing the final release optimizations, but these numbers will give you a ballpark — the working set is not 10’s of bytes nor is it gigabytes.


If you’re interested in performance, let me suggest Rico Mariani’s blog (http://blogs.msdn.com/ricom), he’ll also be at the PDC helping people to their applications. And of course, that age-old wisdom about performance — measure early, measure often!


Comments (0)