Explain how managed code slower than unmanaged code?

"Unmanaged code" is a new name for an old concept.
Unmanaged code stands for native machine code.
Software is typically written in some high-level language such as Pascal, C or C++.
These languages are translated into machine code (aka unmanaged code) by the compiler and its companion tools (assembler, linker, librarian, etc).
The generated code runs natively on the host processor; that is, the processor directly executes the code generated by the compiler.
This approach typically results in fastest code execution, but diagnosing and recovery from errors might be easier in managed code.
"Unmanaged code" is a new name for an old concept.
Unmanaged code stands for native machine code.
Software is typically written in some high-level language such as Pascal, C or C++.
These languages are translated into machine code (aka unmanaged code) by the compiler and its companion tools (assembler, linker, librarian, etc).
The generated code runs natively on the host processor; that is, the processor directly executes the code generated by the compiler.
This approach typically results in fastest code execution, but diagnosing and recovery from errors might be easier in managed code.
Managed code is a new name, but the concept also is pretty old.
Today, "managed code" typically stands for the system used by Microsoft .NET, but .NET is just one example of a managed code system.
The .NET system takes source code in any of the supported languages (which include C, C++, C#, Pascal, and many others), and translates it into code designed for a virtual machine.
The real processor cannot execute this code natively, but it can execute a program which then in turn executes the virtual machine's codes.
The program that executes the virtual machine code is known as the virtual machine.
While potentially slower than native code execution, the virtual machine can manage code (!) better than real machines

Managed Code:- Managed code is code written in one of over twenty high-level programming languages that are available for use with the Microsoft® .NET Framework, including C#, J#, Microsoft Visual Basic® .NET, Microsoft JScript® .NET, and C++.
All of these languages share a unified set of class libraries and can be encoded into an Intermediate Language (IL).
A runtime-aware compiler compiles the IL into native executable code within a managed execution environment that ensures type safety, array bound and index checking, exception handling, and garbage collection.
By using managed code and compiling in this managed execution environment, you can avoid many typical programming mistakes that lead to security holes and unstable applications.
Also, many unproductive programming tasks are automatically taken care of, such as type safety checking, memory management, and destruction of unneeded objects.
You can therefore focus on the business logic of your applications and write them using fewer lines of code.
The result is shorter development time and more secure and stable applications.
UnManaged Code The Microsoft .NET Framework promotes interaction with COM components, COM+ services, external type libraries, and many operating system services.
Data types, method signatures, and error-handling mechanisms vary between managed and unmanaged object models.
To simplify interoperation between .NET Framework components and unmanaged code and to ease the migration path, the common language runtime conceals from both clients and servers the differences in these object models.
Code executing under the control of the runtime is called managed code.
Conversely, code that runs outside the runtime is called unmanaged code.
COM components, ActiveX interfaces, and Win32 API functions are examples of unmanaged code.

in brief if you know the manged code which is c# code for example passing many phases of validations, compiling process, and garbage collector etc.

becuase of garbage collectors and its brothers additional execution time ... plu plu plu plu ...

 

best regards

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.)

Briefly, Managed code not always is slower than unmanaged code.
In managed code, the CLR does some optimization for the way loops, subroutines should run and what is the best way to execute it.