Overhead in transition between managed/unmanaged code

[_BNC]

I've been adapting an older unmanaged C++ legacy app to C#---with limited
success. The original app made use of an older, but straightforward, C
DLL that worked efficiently under the VC++ 6 model.

To adapt to C#, I've wrapped the older DLL calls in an unmanaged C++
class which pretty much just parallels the original function calls and
encapsulates the more ragged aspects (handles, etc).

Then in turn, I wrapped the unmanaged C++ class in a managed C++ class.

All tedious but not real tricky. The C# code seems happy to instantiate
and call the managed C++ class. Preliminary test code executes with no
memory leaks and all execution paths seem intact.

The problem: The internal C DLL has functions that run in a thread.
That thread does not seem to run efficiently in the final C# program.
It's tough to gauge a difference in terms of exec time, but the C DLL's
time-critical code is no longer reliable.

Two reasons occurred to me:

1: The exec-time transition between the C#/C++Managed/C++ Unmanaged code
is very slow. I mean *very* slow. The older app runs fine on older
generation Pentiums.

2: The threading model in the managed code is significantly different in
some way that is affecting the underlying C code.

Ideas or random speculation is welcome.

-----

PS: Is there a code profiler that would be useful for this? The fact that
the code transitions from managed to unmanaged seems tough to handle.

[richlm]

Just a 'shot in the dark'...try hosting your c/c++ code as a component in
COM+ and call it through System.EnterpriseServices. That way you move your
time-critical thread(s) into an "unmanaged" process, which is (presumably)
more deterministic than one managed by the CLR.

For profiling you might try DevPartner Studio from Compuware - you should be
able to get hold of a copy for evaluation.

[_BNC]

On Tue, 9 Nov 2004 11:18:27 +0100, "richlm" <ri*****@h0tmai1.com> wrote:

Just a 'shot in the dark'...try hosting your c/c++ code as a component in
COM+ and call it through System.EnterpriseServices. That way you move your
time-critical thread(s) into an "unmanaged" process, which is (presumably)
more deterministic than one managed by the CLR.

Hey, I'll try anything. Do you happen to know of any example code that
illustrates this?

[_BNC]

On Tue, 9 Nov 2004 11:18:27 +0100, "richlm" <ri*****@h0tmai1.com> wrote:

Just a 'shot in the dark'...try hosting your c/c++ code as a component in
COM+ and call it through System.EnterpriseServices. That way you move your
time-critical thread(s) into an "unmanaged" process, which is (presumably)
more deterministic than one managed by the CLR.

Hey, I'll try anything. Do you happen to know of any example code that
illustrates this?

[richlm]

Sorry don't know of any examples, but you might find some useful info/links
here:

"Improving .NET Application Performance and Scalability"
http://msdn.microsoft.com/library/de...l/scalenet.asp
In particular:
a.. Chapter 7, "Improving Interop Performance"
a.. Chapter 8, "Improving Enterprise Services Performance"

[richlm]

Sorry don't know of any examples, but you might find some useful info/links
here:

"Improving .NET Application Performance and Scalability"
http://msdn.microsoft.com/library/de...l/scalenet.asp
In particular:
a.. Chapter 7, "Improving Interop Performance"
a.. Chapter 8, "Improving Enterprise Services Performance"

[_BNC]

On Wed, 10 Nov 2004 11:15:59 +0100, "richlm" <ri*****@h0tmai1.com> wrote:

Sorry don't know of any examples, but you might find some useful info/links
here:

"Improving .NET Application Performance and Scalability"
http://msdn.microsoft.com/library/de...l/scalenet.asp
In particular:
a.. Chapter 7, "Improving Interop Performance"
a.. Chapter 8, "Improving Enterprise Services Performance"

Thanks for the link, Rich. That should be a great start.

[_BNC]

....

To adapt to C#, I've wrapped the older DLL calls in an unmanaged C++
class which pretty much just parallels the original function calls and
encapsulates the more ragged aspects (handles, etc).

Then in turn, I wrapped the unmanaged C++ class in a managed C++ class.

That thread does not seem to run efficiently in the final C# program.
It's tough to gauge a difference in terms of exec time, but the C DLL's
time-critical code is no longer reliable.

On Wed, 10 Nov 2004 11:15:59 +0100, "richlm" <ri*****@h0tmai1.com> wrote:
Sorry don't know of any examples, but you might find some useful info/links
here:

"Improving .NET Application Performance and Scalability"
http://msdn.microsoft.com/library/de...l/scalenet.asp
In particular:
a.. Chapter 7, "Improving Interop Performance"
a.. Chapter 8, "Improving Enterprise Services Performance"

You know, this brings up an interesting question: How much overhead is
involved in calling back and forth between managed/unmanaged code?
I had expected very little. Any opinions on this? I'm not looking for
hard stats, just subjective experience.