Re: minimizing the cost of managed/unmanaged collaboration

Fernando Tubio <[email protected]> Fri, 30 Mar 2007 11:26:18 -0300
Newsgroups gmane.comp.windows.devel.dotnet.cx
Message-ID <053301c772dc$de1ea3b0$cb1ba8c0@glasgow>
If you choose option 2 and decide to P/Invoke and ".Net security is not an
issue." then I suggest that you take a look at the
SuppressUnmanagedCodeSecurity attribute. By applying this attribute to you
declarations you avoid the full stack walk demand for unmanaged code
permission.

Fernando Tubio

> ----- Original Message -----
> From: "Alan Baljeu" <[email protected]>
> Sent: Thursday, March 29, 2007 11:35 AM
> Subject: Re: minimizing the cost of managed/unmanaged collaboration
>
>
>> 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
>>
>

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

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