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