In a response to my Channel9 video blog post, reader zakimira laments the potential efficiency problems with putting a .NET GUI on top of a native C++ application:
steve, doesnt that add to performance degradation? MFC and Win32 UI stuff is faster and less memory consuming than the WinForms one. (Since they deal directly with the system and winforms is over a .net abstraction layer, or atleast i think so, correct me if im wrong)
MFC is a thin, native code wrapper for the Win32 API, while WinForms is a .NET managed code encapsulation of Win32. Yes, applications that contain managed code tend to consume more memory and they also tend to start up slower due to CLR loading and JIT compilation. Anyone considering "re-skinning" a native app with managed code needs to bear these facts in mind as they choose their implementation path. Assuming the larger memory footprint and slower load time aren't issues (for some they are, for some they aren't), performance of the UI generally isn't a problem for two reasons:
And then a small rant on how wasteful programmers are these days...
Maybe a faster lowlevel UI engine kinda thing can be really good to get the performance upto the mark. i did a small research project on "why today's applications are more memory and performance eaters" and interviewed a teamlead from mentor graphics and he jus said "oh well, cuz thats the industry trend. the memory is so much cheaper now, why not just use it as much as we can". (i was asking him why we cant use the techniques used in RTOS and embedded systems memory management in our daily apps). My argument was, why should msn messenger take as much as 60mb of my 512mb ram, internet explorer should take 70!mb of my 512mb ram at times and the latest visual studio can go over 150mb.... (not to mention some antivirus, a firewall etc). a good degradation of performance.. Yes there are some really slick performance tweaks and memory management going on, (like idle or minimized programs fall back from using memory and let others use their fairshare. but then, the performance overhead of maximizing the same application is nogood).
I really believe the truth is somewhere in between. I'm happy to sacrifice a reasonable amount of runtime efficiency in exchange for better design time productivity and safer, more maintainable code. However, I'll agree that many applications do play too fast and loose with fundamentals like memory consumption and performance. And, of course, memory consumption and efficiency are totally interwoven, since memory hogging applications will cause more paging to occur. My advice: if the performance of the software sucks, don't buy it! We can lament about this together, but it will take good old fashioned economics to change ISV behavior.
And a parting shot:
So a UI library or architecture that emphasis on performance and let the hard-core datastructures of program take hold of majority of the allocated resource rather than the other way round. Enlighten me if im wrong:)
To summarize my thoughts, where UI is concerned, I'm happy to give up bare-metal performance for superior design-time productivity, security, and maintainability. If I'm mixing a managed UI with native code business logic, I try to make the border between native and managed code as efficient as possible, paying particular attention to the amount of data I'm marshaling back and forth and optimizing my algorithms to reduce the number of transitions.
PingBack from http://drugarticle.net/ui-frameworks-and-efficiency/
I disagree with you Steve. 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. You could even see how the upper and lower part of the Ribbon file menu button is beeing drawn when you open the menu. Stupid highlight effects take 100% cpu time. Is this really 2007? I remember on Win 3.0 sometimes you could see how all the lines of the window frame were beeing drawn as well as on Win95 when it run out of memory running several tasks at the same time. Fast forward 10 years, desktop computers are up to 10 times faster and you the UI performance is worse? (Ok, the UI is much shinier today than it was then.)
Contrary to that I need to display realtime data from the engine control unit in a grid view as well as on charts, and I had to slow down the frame rate even on a 800 MHz machine because it's not possible to read text with 40 and more fps. And I haven't even done a lot of optimization, GDI performance is overall great (Don't know yet how much software rendering on Vista impacts GDI performance).
So I don't care about design time productivity, runtime performance is way more important. But why should a great designer impact runtime performance anyway?
Do you expect WPF to replace HWND/GDI based user interfaces entirely in the next years?
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++.
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. Other "thin" Win32 wrappers (ie: MFC, VCL) also have some speed bottlenecks here and ther, due to how were they designed, but they are tones of times faster than WFC.net.
It's sad that in the release notes of the Orcas March CTP is only 1 entry for Visual C++ at the very bottom of the list, and that is only some Vista "look & feel" features.
I hope that there are some "must have" features in the RTM.
It's just crazy, just insane, to generalize the advances in UI design and creation by touting anything relating to performance. The only performance gained is in the software development phase where you can drop on a shinny control and show it off to those that make paychecks. The unfortunate thing is that during that stage, when they adopt your ideas and your technology, they also understand that it's the beta stage so they are expecting more when you finish development.
With .NET you are going to get nothing more than a prototype/beta feel in your applications because of the way it handles memory, collects it's garbage, and does these shinny things. It's faulty logic. A programmer trained in Win32 directly (without MFC, but using dialogs) will always be leaner on memory and present a cleaner UI. It's true that Win32 does not have some super fancy grids that confuse users ... but it's build directly from the frame of the OS so if the OS provided these features then they would be truly native and not mashed up in .NET.
Everything is built upon native applications. Drivers, Win32, and all the cute .NET runtime. I think Microsoft has created it's own tragedy by forgetting the Win32 developers except on the most advanced levels. It was not long ago that ASM was only for the most hardcore programmer ... now that's being extended for the C++ programmer. What a shame.
Client's honestly care less about your fancy framework and care more about what the application does when it's loaded and is working for them. It might take a little longer for a pure Win32 application to be created, but the performance is almost never left wanting.
WinForms is based on GDI+, and
GDI+ drivers do not take advantage of hardware acceleration features built in to the graphics cards fitted to PC systems.
The result is that Winforms is too slow for many applications.
It is incredible to me that Microsoft would release something this cripled as part of its flagship product.
@Bosco: With the new driver model (WDDM) under Vista GDI is also no more hardware accelerated.
Seems like Microsoft wants to push everyone to use DirectX based solutions.
What is Microsoft doing?! Vista is such an unnecessary pig without as much as a handful of useful advances in the OS or PC to PC communications. They should have at least looked at some SSH, or some added web posting/hosting features in all versions.
Now I see that GDI and GDI+ are both second class citizens to the OS in which they live. There are many very good applications out there are require GDI/+ to run the best it can and now all of those application just got a downgrade. GDI+ at least had some surface items in the underbelly and now that's all ... well, whatever it is ... I'm sure it's not very good.
Having hardware acceleration for native GDI/+ applications should have been a priority to MS so when we test our applications on the new OS we will see a perf boost. Now, I guess it's Linux time.
Thanks for the reply steve. :) Id like to carry on the discussion, but maybe we diverge at the point of siding with application performance vs programmer productivity increase. None the less .Net is a great framework which i see has a lot of future. I think it should do a lot more on getting the compact framework out and more compliant on wide range of hand held devices. right now j2me seems to win the market.
ps: iv put you on my blogroll:)
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).
A lot of great energy in the comments on my last post on UI Frameworks and Efficiency . It turns out