Styjun

When I changed the DLL build options from native to /CLR, so that I could debug across the c#/c++ boundary, my performance was cut in half.

I developed a native C++ DLL with specific high performance algorithms to solve my computational problems. This DLL I needed to plug into a C# application developed by a business partner and it is used to replace their lower performance algorithm. All was going great, I plugged in my DLL using static wrapper calls, the DLL algorithm was working great showing a 2x performance improvement over original algorithm, but could not debug across boundary.
I then switched the c++ DLL build settings from native to /CLR in order to be able to debug across the c#/c++ DLL boundary and my performance dropped in half.

Cannot figure out why that is the case.

c++ DLL side:

extern "C"

 __declspec(dllexport) void* NewCalc()
 
 return (void*)new CalcCL;
 
 __declspec(dllexport) double Calc(void* sCalc, int *Buf, int Cnt)
 
 return ((CalcCl*)sCalc)->Calc(Buf, Cnt);
 

c# side:

 [DllImport("CalcDLL.dll", CallingConvention = CallingConvention.Cdecl)]
 public static extern int NewCalc();
 [DllImport("CalcDLL.dll", CallingConvention = CallingConvention.Cdecl)]
 public static extern double Calc(int sCalc, int[] Buf, int Cnt);
...
 int sCalc = NewCalc();
...
 double res;
 int[] MyBuf = new int[1000];
 // <Code that fills MyBuf with target data for algorithm>
 res = Calc(sCalc, MyBuf, 1000);

With the given interface there is no benefit to compiling with /clr at all. Make the native C++ code debuggable by right-clicking your main C# project > Properties > Debug tab > tick the "Enable native code debugging" checkbox. That enables both the managed and unmanaged debugging engines. You cannot single-step into the native code, a breakpoint on the Calc() function is required to effect a debug engine change. You might still favor a unit test written in native C++ if setting breakpoints is awkward.

The other thing you need to take care of is that you're building the C++ code with Debug settings enabled. You got that now, that's why the code seems to be half as slow. Only do a perf test with Release build settings so you're sure that the optimizer is enabled. Best thing to do is to include the native C++ project in the C# solution so you always build the right flavor. And you have to make sure that the correct DLL gets copied into the C# main project's build directory, usually done with a post-build event. That copy step must be different for the Debug and Release configurations.

Note that the [DllImport] declarations are not correct. The return type of NewCalc() must be IntPtr so it also works in 64-bit code. Perf-testing the 64-bit build of the C++ code is something else you want to try, it can boost perf if the Calc() function uses floating point math. Actually using /clr can be useful to make the interface better, you'll however have to learn how to write C++/CLI code and avoid building the native C++ code with /clr.