Coffeehouse Thread

9 posts

Forum Read Only

This forum has been made read only by the site admins. No new threads or comments can be added.

Win32 vs. MFC vs. .NET

Back to Forum: Coffeehouse
  • User profile image
    Cornelius Ellsonpeter

    I'm curious...what are the performance differences between code written with the C/Win32 APIs, MFC and .NET? I know it may take longer to write code using the C/Win32 APIs, but does it execute faster than using MFC? Does Microsoft use the C APIs internally, or do they use MFC to any extent? How about .NET?

  • User profile image
    Sven Groot

    Cornelius Ellsonpeter wrote:
    I'm curious...what are the performance differences between code written with the C/Win32 APIs, MFC and .NET?

    The answer is that, as with so many things, it depends. There are things that managed code is good at and things that native code is good at. There's no single answer I can give you here.

  • User profile image
    Stebet

    For "normal" applications i doubt you'd be able to tell the difference. For realtime applications and hardcore math apps you'd propably want to stick with C/C++.

    Design and algorithms are much bigger factors in performance than programming languages.

    .NET has JIT costs and overhead because of it's automatic memory management for example but it is however a lot more productive to write stuff in .NET (much fewer lines of code required) and as the .NET runtime and BCL matures the performance difference between it and C/C++ is becoming less and less.

  • User profile image
    Stebet

    Sven Groot wrote:
    The answer is that, as with so many things, it depends. There are things that managed code is good at and things that native code is good at. There's no single answer I can give you here.


    I agree completely. It all depends on what your performance metrics are.

  • User profile image
    Cornelius Ellsonpeter

    Stebet wrote:
    
    Sven Groot wrote:
    The answer is that, as with so many things, it depends. There are things that managed code is good at and things that native code is good at. There's no single answer I can give you here.
    I agree completely. It all depends on what your performance metrics are.
    So I take it that the Office Team (for instance) doesn't use .NET in any tangible way? How about MFC? Or do they code it all up in mostly C/C++ with frameworks that do not ship to the public?

  • User profile image
    Soviut

    Stebet wrote:
    .NET has JIT costs and overhead because of it's automatic memory management for example but it is however a lot more productive to write stuff in .NET (much fewer lines of code required) and as the .NET runtime and BCL matures the performance difference between it and C/C++ is becoming less and less.


    In recent video interviews on C9 with the designer of the garbage collector in .NET, he discussed the fact that the GC can actually optimize itself on the fly.  Tuning itself to suit different types of operations, memory structures, and volumes.

    In many cases, the GC can now outperform most C++ application memory management that was done by hand because of the amount of work to do dynamic load balancing and performance metering inside an application.

  • User profile image
    Royal​Schrubber

    Soviut wrote:
    
    Stebet wrote:
    .NET has JIT costs and overhead because of it's automatic memory management for example but it is however a lot more productive to write stuff in .NET (much fewer lines of code required) and as the .NET runtime and BCL matures the performance difference between it and C/C++ is becoming less and less.


    In recent video interviews on C9 with the designer of the garbage collector in .NET, he discussed the fact that the GC can actually optimize itself on the fly.  Tuning itself to suit different types of operations, memory structures, and volumes.

    In many cases, the GC can now outperform most C++ application memory management that was done by hand because of the amount of work to do dynamic load balancing and performance metering inside an application.


    And if safe c# can't deliver raw power you can use c++/cli, it's win win situation for .net Smiley

  • User profile image
    Cornelius Ellsonpeter

    Soviut wrote:
    In recent video interviews on C9 with the designer of the garbage collector in .NET, he discussed the fact that the GC can actually optimize itself on the fly.  Tuning itself to suit different types of operations, memory structures, and volumes.

    In many cases, the GC can now outperform most C++ application memory management that was done by hand because of the amount of work to do dynamic load balancing and performance metering inside an application.
    That's interesting. Does that mean that C++ development (in terms of VS) is pretty much going to be considered a second class language? Does that mean they will be using .NET more internally to develop software...considering that the performance improvements are so exemplary?

    I don't want to spend learning framework after framework, only to be told "the future is with the [XYZ] framework or whatever" and then to see them build their own products with something completely different.. It gets kind of old, ya know?

  • User profile image
    Sven Groot

    If you're looking for internal Microsoft usage of .Net, the biggest I can think of is microsoft.com; pretty much the entire site (and related sites like MSDN too) is ASP.NET (some leftover ASP parts, but it's getting converted little by little).

    Large parts of Visual Studio are managed code. The Expression suite of products is all .Net. Etc.

Conversation locked

This conversation has been locked by the site admins. No new comments can be made.