Is there generally a noticeable performance hit when calling PInvoke on Win32 / COM methods?

Question

I\'m wondering whether anyone has a decent explanation or overview on the negative aspects of using DLLImport / PInvoke on Win32 methods from managed .Net code?

I plan t

Answer 1

According to MSDN - Calling Native Functions from Managed Code

PInvoke has an overhead of between 10 and 30 x86 instructions per call. In addition to this fixed cost, marshaling creates additional overhead. There is no marshaling cost between blittable types that have the same representation in managed and unmanaged code. For example, there is no cost to translate between int and Int32.

In my experience, there definitely is an overhead when P/Invoking native functions, but usually the performance hit isn't worth worrying about. The marshaling cost is something to keep in mind. If you are passing in large structures, strings, etc. then the performance costs will quickly show.

For P/Invoked functions that are called very frequently, you may want to consider adding [SuppressUnmanagedCodeSecurity] to your P/Invoke function definitions (see MSDN - SuppressUnmanagedCodeSecurityAttribute). This stops the runtime from doing a stack walk to ensure the caller has UnmanagedCode permission. Of course, make sure you understand the security ramifications before adding this attribute.

Answer 2

Here are some issues I see with PInvoke:

• Parameter marshaling can be expensive, depending on the data type (blittable / non-blittable)
• Correct parameter marshaling is often not very intuitive
• PInvoke does not provide any compile time security. One can easily misspell DLL or function names easily without the compiler complaining.

If you plan to use lots of unmanaged functions I would create a mixed DLL (http://msdn.microsoft.com/en-us/library/x0w2664k.aspx) rather than declaring a bunch of PInvokes.