C# -> C++ Performance

[Toadfather]

Hi all
Existing COM ATL DLL wrapping a C++ library. Interoping from a C#
application, passing a large string containng XML (5-130kb). Need to
significantly improve performance of both the interoping and the
performance of the native functions (performance critical app).

Opinions sought on most worthwhile course of action...have identified 4

options...

1. Implement a managed C++ wrapper and link to underling C++ functions,

marshalling non-native types where necessary. Thus eliminating COM
(quick win?)
2. Re-write C++ code in C#. (no quick win, not possible to re-write all

of it also)
3. Recompile C++ code with VC7 or higher (currently VC6)...quick win?
4. Re-architect C++ code (no quick win)

Thanks all

 

[GhostInAK]

Hello Toadfather,

Are your C++ functions sufficiently speedy on their own already?

I see two things.. First, COM interop in .NET is always going to be slow.
Specifically COM object instantiation.

Second, XML parsing is a tad slow as well.

The XML parsing is probably unavoidable, but try to limit the COM interop
as much as possible.

-Boo

 

[Guest]

What exactly hinders the performance?
C# XML parsing, C++ XML parsing or IPC?

for any case there are different solution - from changing the way of parsing
data to zipping message and sending in between apps

Hi all
Existing COM ATL DLL wrapping a C++ library. Interoping from a C#
application, passing a large string containng XML (5-130kb). Need to
significantly improve performance of both the interoping and the
performance of the native functions (performance critical app).

Opinions sought on most worthwhile course of action...have identified 4

options...

1. Implement a managed C++ wrapper and link to underling C++ functions,

marshalling non-native types where necessary. Thus eliminating COM
(quick win?)
2. Re-write C++ code in C#. (no quick win, not possible to re-write all

of it also)
3. Recompile C++ code with VC7 or higher (currently VC6)...quick win?
4. Re-architect C++ code (no quick win)

--
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

 

[Ben Voigt]

Hi all
Existing COM ATL DLL wrapping a C++ library. Interoping from a C#
application, passing a large string containng XML (5-130kb). Need to
significantly improve performance of both the interoping and the
performance of the native functions (performance critical app).

Opinions sought on most worthwhile course of action...have identified 4

options...

1. Implement a managed C++ wrapper and link to underling C++ functions,

marshalling non-native types where necessary. Thus eliminating COM
(quick win?)

This is definitely a good way to improve performance.

2. Re-write C++ code in C#. (no quick win, not possible to re-write all

of it also)
3. Recompile C++ code with VC7 or higher (currently VC6)...quick win?

This is the quickest and easiest. You have two options if combining with
#1:
Recompile as native (almost zero effort needed) -- the new C++ compilers
have improved optimizers, may help some.
Recompile with /clr. This will invoke the C++.NET "It Just Works" feature
and compile to MSIL. Is your C++ code purely data massaging, or does it
make Win32 API calls (network, file, etc)? If you are only working with the
data, then using /clrure will eliminate the managed-unmanaged transitions
for some more gain. If you are doing I/O or using other COM objects, etc,
then you will want to use #pragma managed/#pragma unmanaged to minimize the
number of transitions.

4. Re-architect C++ code (no quick win)

Here it may be worthwhile to refactor the code a little bit. Any rework you
do should be with the goal of preventing the following scenario:
Your managed C++ wrapper copies a 10 megabyte string to unmanaged memory,
and calls the original C++ function, which takes one look at an integer
parameter, chooses not to use that massive string for some other reason.
Try to cache the converted strings. Try to work on the strings in Unicode
to avoid conversion.