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