none
Why is Managed Code slower than Unmanaged RRS feed

  • Question

  • I come from .NET and am trying to learn more about lower-level languages (C++/C) to understand when performance benefits would occur from writing unmanaged code versus managed code.  I was looking at pipes and got to thinking: when a function is called in the FCL does it slow down because the code has to run the natives opcodes and the interpreted code (.NET)?  Or, is there more to it?  For instance, when I use some Win32 function to create a pipe, I am directly passing handles in C or C++.  With .NET almost everything is variables (and hence, lookups) and references.  Is it correct to think that the unmanaged code simply has less steps to complete each operation due to the absence of the interprertive layer?
    Wednesday, January 27, 2010 11:20 PM

Answers

  • "Why is Managed Code slower than Unmanaged"

    This is, IMO, a false assumption to make right at the start.

    Managed code tends to be higher level than unmanaged code.  When working with a higher level language, more of the decisions have been made for you - and since they're trying to work in a general purpose case, it may not perform as well for every specific use case

    However, most developers don't spend as much time optimizing each individual portion of code, and the framework tends to be optimized fairly heavily.  Because of this, programs written in managed languages actually, often, perform better than ones written in unmanaged code.

    If you fully optimize both versions, though, you can probably get a (very slight) improvement in performance in the unmanaged side.  There are some extra things happening in .NET, such as the GC, JIT compilation, etc, that cause reduced performance.  You also do, often, have an extra layer of method calls when translating from nice .NET objects into the underlying Win32 API calls, which again adds a very, very small amount of overhead.

    For practical purposes, though, this is meaningless.  The real performance differences typically come from optimizing your algorithms, not your specific code in a specific language.

    (This also completely ignores all of the advantages of managed code, such as safety, producivity, etc.)
    Reed Copsey, Jr. - http://reedcopsey.com
    • Marked as answer by Will Steele Thursday, January 28, 2010 3:12 PM
    • Unmarked as answer by Will Steele Thursday, January 28, 2010 3:12 PM
    • Marked as answer by Will Steele Thursday, January 28, 2010 3:13 PM
    Wednesday, January 27, 2010 11:41 PM
    Moderator

All replies

  • "Why is Managed Code slower than Unmanaged"

    This is, IMO, a false assumption to make right at the start.

    Managed code tends to be higher level than unmanaged code.  When working with a higher level language, more of the decisions have been made for you - and since they're trying to work in a general purpose case, it may not perform as well for every specific use case

    However, most developers don't spend as much time optimizing each individual portion of code, and the framework tends to be optimized fairly heavily.  Because of this, programs written in managed languages actually, often, perform better than ones written in unmanaged code.

    If you fully optimize both versions, though, you can probably get a (very slight) improvement in performance in the unmanaged side.  There are some extra things happening in .NET, such as the GC, JIT compilation, etc, that cause reduced performance.  You also do, often, have an extra layer of method calls when translating from nice .NET objects into the underlying Win32 API calls, which again adds a very, very small amount of overhead.

    For practical purposes, though, this is meaningless.  The real performance differences typically come from optimizing your algorithms, not your specific code in a specific language.

    (This also completely ignores all of the advantages of managed code, such as safety, producivity, etc.)
    Reed Copsey, Jr. - http://reedcopsey.com
    • Marked as answer by Will Steele Thursday, January 28, 2010 3:12 PM
    • Unmarked as answer by Will Steele Thursday, January 28, 2010 3:12 PM
    • Marked as answer by Will Steele Thursday, January 28, 2010 3:13 PM
    Wednesday, January 27, 2010 11:41 PM
    Moderator
  • Thanks for the input.  I see your points and appreciate the feedback.  Focusing on algorithms instead of details makes good sense.
    Thursday, January 28, 2010 3:14 PM