Is p/Invoke bad for performance?

[jhammer]

I have some code written in C++ libraries, and also I need access to some WinAPI32 functions.
I've read about p/Invoke and marshaling and used it a little bit. It works.

I'm wondering what are the costs of the calls to unmanaged code from C#. Am I better off writing the code in C# (I'm not talking about GUI or Database, but some really efficient code)? Is using p/Invoke a bad idea, or a bad practice?

[hspc]

From MSDN:
With every transition from managed code to unmanaged code (and vice versa), there is some performance overhead. The amount of overhead depends on the types of parameters used. The CLR interop layer uses three levels of interop call optimization based on transition type and parameter types: just-in-time (JIT) inlining, compiled assembly stubs, and interpreted marshaling stubs (in order of fastest to slowest type of call).
Approximate overhead for a platform invoke call: 10 machine instructions (on an x86 processor)

Approximate overhead for a COM interop call: 50 machine instructions (on an x86 processor)

The work done by these instructions is shown in the appendix sections Calling a Flat API: Step by Step (http://msdn.microsoft.com/library/en-us/dndotnet/html/manunmancode.asp?frame=true#manunman_flatapicall) and Calling a COM API: Step by Step (http://msdn.microsoft.com/library/en-us/dndotnet/html/manunmancode.asp?frame=true#manunman_comapi). Besides ensuring that the garbage collector will not block unmanaged threads during the call, and handling calling conventions and unmanaged exceptions, COM interop does extra work to convert the call on the current runtime callable wrapper (RCW) to a COM interface pointer appropriate to the current context.

Every interop call introduces some overhead. Depending on how often these calls occur and the significance of the work happening inside the method implementation, the per-call overhead can range from negligible to very noticeable.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/manunmancode.asp

[jhammer]

Thank you for that, I found other resources that told me the same.
But I couldn't find anything regarding the question: Is it a good or bad practice to use pInvoke in C#?

[Shuja Ali]

Thank you for that, I found other resources that told me the same.
But I couldn't find anything regarding the question: Is it a good or bad practice to use pInvoke in C#?
This is what I found on net
PInvoke does have a few drawbacks. It is not always that easy to define the correct function signature and the diagnostics to help in this are nearly non-existent. Then there is the portability issue, when working with Mono or DotGNU where do we stand, will my PInvoke work. Using Mono on WINE might alleviate this issue to some extent, where we stand with DotGNU I do not know, I have never tried DotGNU so any answer would only be a guess on my part. But it is safe to say that the more you rely on PInvoke the less portable your software will be. You also require unmanaged code permissions for PInvoke to function in a secure environment.