steve clark wrote:
We've noticed that invocations of legacy C++ COM DLLs from .NET
(Managed C++ or C#) desktop applications is quite a bit slower than
the same calls from good old native C++.
Does anybody have specific information about why this would be the
case? How about performance numbers, benchmarks, etc? Any
suggestions to speed up the connection between new .NET code and
legacy C++?
Microsoft says that the thunking in platform invoke (and hence COM interop,
which is a specialized form of p/invoke) is 20-30 CPU cycles, not a huge
amount for a single call, but could be large if you are making many calls
from .NET to COM. Here's somethings to consider:
1) what is the threading model of the COM object? By default .NET threads
will be MTA, but the VS.NET wizards always makes the entrypoint thread STA.
You can gain some performance by making sure that the .NET thread is the
same apartment type as the .NET object (and hence they will run in the same
apartment and you don't have apartment marshalling).
2) how 'chatty' is the COM object? If it was designed to be an inproc
server, the designer did not have to think about marshalling issues (because
it is in-apartment) so the interaction with the client could be 'chatty' -
lots of calls. If this is the case then maybe you are amplifying the effect
of the thunks. To get round this you could write a shim native C++ DLL that
batches the calls to the object. From memory, Chris Sells wrote such a shim
to make IEnum calls from VB code to a COM object more efficient. (classic VB
calls makes many IEnumXXX::Next calls, each getting a single item -
inefficient for IPC calls).
Richard
--
my email
ev******@zicf.bet is encrypted with ROT13 (
www.rot13.org)
