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:

  1. Managed code is compiled into native code before it is executed, so once a managed code app is loaded into memory and JIT'd, there is no performance penalty.
  2. UIs only need to run at human speed, so even a runtime-interpreted UI would be fast enough for all but the most demanding UI needs (e.g., animation, video, displaying large data sets, etc.).

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.