"Speed" is pretty subjective.  Do you mean speed to market or execution
speed?

Any sort of PInvoke is a trade-off between ease of maintenance (read speed
to market) and speed of execution.

IJW (VC2003) and C++ Interop (VC2005) are means to get existing logic
written in native C++ into the managed arena faster.  While generally
using IJW/C++Interop is a faster running means of PInvoke over manually
creating the marshaling structures and declarations yourself, it's meant
to integrate your code faster rather executing as quickly as possible.

BTW, IJW and C++ Interop don't apply to COM--that's a separate beast.  IJW
and C++ interop always work in-process.  Depending on your COM object, it
may be operating very slowing out-of-process.

The general means of progression is to gradually move from a mix of
managed and unmanaged code to all unmanaged (or a majority thereof).
Going the COM route introduces a non-value added layer that does nothing
for performance.  The IJW/C++Interop route means you create managed
wrapper classes for your existing C/C++ API/Classes.  As you migrate your
existing C/C++ code to managed code, what happens behind the wrapper
classes is just an implementation detail and eventually you're left with a
completely managed code base.  The COM route you have a COM layer
affecting your performance or the extra time spent to remove that layer.

In terms of the details, PInvoke is generally pretty performant.  One
thing it does do is enforce the implied read-/write-ability of the
parameters PInvoked.  For example, if you define a function void Function
(MyStruct data), the pinned memory given to the native code will be read-
only.  If you define a function void Function(ref MyStruct) the pinned
memory given to native code will be read-write.  This, of course, takes a
bit more time to accomplish (changing virtual memory permissions, pinning,
unpinning, etc.).  But, again, implicit PInvoke like IWJ/C++Interop is a
means to migrate code, the "costs" are somewhat academic as you're
incurring those costs only temporarily while you migrate everything to all
managed (and more performant) code.  There's also the implications of CAS
that you have to deal with.  At least with C++ Interop there's mandate
that the assembly wrapping the C++ code *must* have run-safe-code
permission. (this is one thing that makes it very difficult to use C++ in
ASP.NET)

Other than that, maybe you can provide more detail on what "costs" you're
talking about.  For the most part, "costs" are application-specific.

On Wed, 28 Mar 2007 15:35:10 -0400, Alan Baljeu
<alanb@CORN...> wrote:

>Peter Ritchie writes:
>> In terms of using your native API from managed, out of the
>> box; I don't think there's anything specific for general
>> performance between managed/unmanaged code.  With VC2003,
>> using IJW will be faster than doing the PInvoking yourself
>> (or so I'm told).
>
>I understand you to mean that using COM declarations in C# and C++ is the
faster way to
>operate compared to declaring C API's in C# and calling them.  If not,
please correct me.
>
>> As you incrementanly move your native to managed you'll be
>> able to get some performance metrics and test performance
>> increases/decreases.
>
>I prefer writing in C#, but it isn't possible to go completely to managed
code.  As speed is
>an issue, perhaps I ought to migrate code in the other direction.  I
would migrate some code
>across the boundary in one direction or the other, if I had a good
understanding of the
>costs of crossing that barrier, and knew that it was significant.  If
anyone can direct me
>in obtaining this understanding, please speak up.

===================================
This list is hosted by DevelopMentor®  http://www.develop.com

View archives and manage your subscription(s) at http://discuss.develop.com