A lot of great energy in the comments on my last post on UI Frameworks and Efficiency. It turns out that most of the energy was devoted to vociferous disagreement with my opinion, which I actually think is cool because it creates the opportunity for a conversation. :)
There are a number of comments along the lines of "these darn managed code frameworks are fat, slow, flickery, and CPU-hogging." Let me give you three comments that are representative of the majority of issues. First, reader Andre writes:
I've compared several UI toolkits, MFC as well as WinForms, and except two all others were unusable. The first thing I try is resizing the window and see if the window follows the mouse smoothly. My experience with those toolkits were horrible, flickering and the window repaints once a second on a 3 GHz machine.
On his own blog, old friend Marco Cantu writes:
I have to say the he misses one of the efficiency points, as .NET applications with a UI slow down because of the marshalling and protection of the Win32 API calls, not because of the nature of IL.
Finally, reader Me says:
If you decompile WFC .net managed code (using Reflector for example), you'll see it does lots and lots of things until it gets to Win32 dll layer. For me all this extra work takes much more time during the whole app life than startup clr and jit.
These comments represent the three issues that seemed to float to the top for folks: the perception that managed code frameworks are slow, the overhead of native/managed marshaling, and the relative thickness of the managed frameworks.
Let me first respond to these comments in general: Yes, I agree that managed frameworks are generally going to require better hardware for comparable performance. For some people, that's a major issue, which is fine and one of the reasons we continue to invest in things like MFC.
To the first issue, I would say: let's not damn managed UI frameworks in general because of the issues with WinForms. As reader Bosco points out, WinForms isn't hardware accelerated. WPF, by contrast, performs far better than WinForms in visualization-intensive apps. For example, here in DevDiv we have a major project where the team chose to "re-skin" an MFC application with a WPF UI. The application core remains in native code, and the look & feel of the UI is way better than the old one with no noticeable performance loss.
Which foreshadows the second issue: interop. Native/managed interop is definitely one of those areas where it's easy to do the wrong (i.e., inefficient) thing. While there is still much room for Microsoft to improve interop performance, this is not a dealbreaker for most UI scenarios if the interop layer is well designed. Case in point: Visual Studio 2005, which contains significant native/managed interop. Why I'll fully agree performance could be better in areas, it's quite good overall, and I would consider it a success story for successful use of interop in a UI.
Regarding the relative thickness of the framework, sure, a lot can happen in between the user calling a framework API and the API calling the underlying GDI or DirectX thing. Again, I'm not arguing that managed frameworks are every bit as efficient as a think native wrapper. I'm arguing that the large boost in developer productivity is often worth the typically small performance cost.
Now, to answer a couple of specific related questions I noticed in the comment stream for this entry. First, reader Andre asks:
Do you expect WPF to replace HWND/GDI based user interfaces entirely in the next years?
No. I expect lots and lots of people to use WPF, but I don't expect HWND/GDI based UIs to go away for the foreseeable future. Andre also asks:
On a sidenote, there is a huge gap between the january CTP and what you are promising in the Channel 9 video. I guess the "big investments" haven't been integrated yet, currently I couldn't even tell a difference with VS2005 for C++.
The "big investments" Bill and I discussed in the Channel 9 video won't start to appear until the next Visual Studio release after Orcas. Although we started this work during the Orcas cycle, the work involved is significant, so we won't have anything customer-ready until Orcas+1. Our first priority with this work is to greatly improve the experience around Intellisense and code-focused IDE tooling in general. We've detailed a lot of the Orcas features on the Visual C++ team blog.
Finally, zakimirza puts in:
Oh and can you comment on why there has been a huge shift in frameworks so quickly. I mean, we were in the GDI reign one day.... a couple of years later we migrated to the GDI+ towns in .Net 1 and then in .Net 2..but suddenly we have WPF all around. Also, how much is microsoft using .Net itself in its top of the line products(for what i know and listening to sumit chohan, the manager at Microsoft Access, most of the code is native C/C++ code).
Well, let's talk about the framework shift thing first. I have my own theory on this, which I'll share with you. While it would be great to have One UI Framework to Rule Them All, my observation is that software development technology continues to evolve at a rapid pace, such that it is far more practical to design new frameworks to accommodate new patterns & technologies than it is to retrofit old frameworks. This kind of jumps out at you if you just take a couple of steps back a look at the evolution from GDI's C API to MFC's hierarchy + bag of classes approach to WTL's templated C++ classes approach to WinForms' language-agnostic but clearly J++/WFC and Delphi/VCL-derived model to WPF's XAML approach for better integration between developers and designers.
As to how much we're using .NET in our own products, the answer is that we're doing the same things we're telling ISVs to do. If we have investments today that are substantially native code, they're going to stay that way unless there is a compelling business reason to change course. Probably the biggest example of where we've added managed code today is Visual Studio. We have another couple of other interesting projects going on in DevDiv, one is the WPF UI with native code that I mentioned earlier and the other is a new app build entirely in C#. Another example is Office 12, which uses managed code for much of the new server-side technology, while keeping the existing client-side investments predominantly native.
