Speed to market is important too; if you can't get something out before
your competitors or before another technology is available, how fast your
code is is irrelevant.

There's always caveats and we can't possibly know all of your details, but
unless you've got a COM interface to your C++ code already I don't see a
need to go that route.  You mention you've got native code that simply
can't be made managed; for that COM might be an option; especially if you
want to use that from other code that may be native.  COM is similar to
IJW in that you don't have to manually create the data types on the
managed side.   If you want a physical separation of binaries COM might
also be a better choice.  I don't think it was mentioned but the
IJW/C++Interop routes assumes the native code is contained within the
managed assembly.  So, if you do need to reuse the native code, even
temporarily, IJW might be more work than is necessary (i.e. writing a
native wrapper to the DLL that your managed wrapper would communicate
with, two wrappers...).

If security were an issue COM might present some hurdles.

"academic" in that if you have to go that route there's nothing you can do
about it--other than know the costs.

I guess we need to know if you need that physical separation... once we
know that the answers should be fairly obvious.

On Thu, 29 Mar 2007 10:35:49 -0400, Alan Baljeu
<alanb@CORN...> wrote:

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

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

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