opensubscriber
   Find in this group all groups
 
Unknown more information…

d : dotnet-cx@discuss.develop.com 2 April 2007 • 10:47PM -0400

Re: minimizing the cost of managed/unmanaged collaboration
by Fabian Schmied

REPLY TO AUTHOR
 
REPLY TO GROUP




Hi Alan,

Unfortunately I'm no expert on managed/unmanaged interop performance
either, however I want to point you to an MSDN article that might be
useful to you: "Improving Interop Performance"
(http://msdn2.microsoft.com/en-us/library/ms998551.aspx).

In essence, I think the following problems mentioned in the article
might be most relevant to your situation:

- Marshaling parameter types inefficiently,
- Using chatty interfaces that require excessive round trips,
- Overhead of Unicode to ANSI string conversions.

There is also a section on how to monitor the interop performance of
your application.

> I figure somehow I need to
> compile some of my C++ code as managed, but I'm not clear on how to make that work given the
> need to also connect to native code.

I've seen your other post on this issue. Compiling part of your
application in unmanaged C++ and the other part in C++/CLI (.NET 2.0)
or Managed C++ (.NET 1.1) should be possible, however in practice it's
not always that straight-forward.

Also, because of the implicit interop mechanisms (IJW and C++
Interop), the boundaries between managed and unmanaged code become
somewhat blurred, which might be a nuisance if you want to analyze
these boundaries. So maybe it would be easiest to interface your
unmanaged code via ordinary P/Invoke from C# (in .NET 2.0 performance
of P/Invoke should be about the same as C++ Interop, I think) and use
the techniques from the article to optimize this interface.

Regards,
Fabian

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

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

Bookmark with:

Delicious   Digg   reddit   Facebook   StumbleUpon

Related Messages

opensubscriber is not affiliated with the authors of this message nor responsible for its content.