C++/CLI performance gain

Question

I started long ago with plain C, then moved to C++ and now I'm facing C++/CLI. As a performance freak, I'm always trying to squeeze the last drop of performance to every line of code. I'm currently in a project that makes sense to be done mostly in VB.Net (simplicity, resource availability, etc.), but has a few points that are very performance sensitive and I was planning to do those parts in C++/CLI. However, only a tiny portion of it can be taken out from managed code, while the rest needs to be kept managed. The question is, is there any performance gain to be expected by writing a C++/CLI managed function comparing to C# or VB.Net? From what I could understand from the docs I've been reading, the only advantage seems to be that managed/unmanaged thunking is lighter. Is that the case? Because I can't even seem able to store handles in unmanaged arrays or structures (which I could manipulate faster), like:

String ^ mystr = "Oh, my!";
Object ^ myarray[10];
myarray[0] = mystr; // Can't event be casted to void*, int, HANDLE...
// (however, handles do have a sizeof() == 4 in Win32)
// (I don't expect the handle to behave like a pointer; just stay as handle)

Answer 1

There's no performance advantage as C++/CLI compiles to MSIL, just like C# and VB.NET. You can write some simple test functions in both VB and C++/CLI to see for yourself.

Answer 2

The only performance gain you might see with C++/CLI is where you mix native and managed code. C++/CLI allows you to call native methods for performance critical sections of code with less of an overhead than VB.Net. I wouldn't recommend switching between native and managed all over the place, as there is still a penalty, but passing control to native code for a chunk of performance related code is acceptable.

Answer 3

I'm a performance freak too, and I've learned that

1. This kind of question is not something I even ask until I know where the performance problems are,

2. Once I do know where they are, I don't need to ask, because I can easily find out, because a) all compiled languages generate assembly or intermediate language that I can look at, and b) I can run it 10^6 times and just clock it.

My experience is there are multiple performance problems, having a range of sizes. First I fix the ones that are easiest / biggest. That makes the rest of them take a larger percent of the time so they are easier to find on the next pass.**

I keep doing tuning passes until I run out of performance problems I can fix. By that time the code can be way faster than it was to begin with.

** Example: Suppose the program takes 10 seconds. Suppose there are two problems (you don't know till you look) and they take 50% and 30%, respectively. You fix the first one, and time drops to 5 seconds. Now the second problem is consuming 60%, because the total time has decreased, so it is much easier to spot. Fix it and time drops to 2 seconds - a 5x speedup. The more problems there are, the more dramatic the possible speedup. One may doubt that they have such large problems, and if so, sampling will prove or disprove it.

Answer 4

C++/CLI is managed - it is compiled into the same MSIL as every other .net language. if speed is king for you, write the critical bit in a native dll and pinvoke it from your vb.net app (keep the thunk count down and you should be fine).

though tbh, id first profile the code to see if this is really necessary and not just premature optimisation. MSIL can be/is compiled into native code anyway - the real question is whether the .net JITer is as good as optimising as the native c/c++ compiler.

Answer 5

By the way, to store handles in unmanaged portions of memory, I just needed to use the GCHandle structure or gcroot.