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 (https://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!