Hi Peter.  Thanks for your input.  It is helpful, and presents a way forward to me.

But first to get this out of the way:
> "Speed" is pretty subjective.  Do you mean speed to market or
> execution speed?
I'm astonished by the question.  I thought I had been abundantly clear that my query is how
to obtain faster execution time.  Speed can be objective, in that it can be measured.

-------------
About my program: It seems I should have written this explanation earlier.  I apologize for
leaving all of you to your imagination.

Originally everything was completely native-code, but the program was still in development
at that time.  Currently, I have some managed code and some native code.  My native code is
C++ and statically links to a large amount of other native code which cannot be migrated to
a managed environment.

I use C# for the managed code because it's easier; otherwise I would be operating strictly
in native mode.  Execution speed is an issue now, so I'll look at whatever changes are
necessary to improve speed provided this doesn't make maintenance too hard.  However, it is
impossible to reduce the *amount* of data being communicated, because the information is
kept in managed storage, and used by unmanaged libraries.  It is only feasible to change how
it is communicated.

.Net security is not an issue.

My C# libraries are currently exposed to C++ through inprocess COM, because this was easy.
95% of the communication bandwidth between .net and native code consists of native code
calling COM methods defined in C#.  5% is C# code invoking native code through COM.  Again,
that's because it was easy.
----------------
>From your letter, I understand that COM is relatively inefficient for interoping.  I am
totally open to changing not using COM if that is considered a performance issue.

For my context (where most of the cost is calls from C++ to c#) that seems to imply I use
another technique to call from C++ to C#.  This seems to mean I should compile my C++
libraries as managed code.  I always suspected this would be a difficult process as I would
then need to still use a lot of native stuff, but mix in managed calls.  (And COM import was
easy so I never tried.)

The other option is that I reconfigure my code so that most of the calls are from C# to C++.
Then I could use PInvoke or IJW like you suggested.

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

This explanation is helpful for understanding performance.  However, I don't agree that it's
academic in my situation because I won't be migrating everything to managed code.  So my
options appear to be:

1. Attempt to convert my C++ code to mixed managed/unmanaged code, and eliminate use of COM
for interop.
2. Rewrite the code so that C# calls C++, sending data via PInvoke or IJW. (But which and
why?)

Alan

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

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