Repeatedly I saw software engines based on .NET virtual machine with C++ staffs. Of course, if an engine is intended for .NET auditory it’s the good way to expose exuberant .NET API. However, the question that worried me was when it is time to migrate to a virtual machine when much performance-critical logic must be written. How this logic is slowed down when it is under managed environment.
Immediately I must say that there is another critical-performance niche where C++/C might be combined with assembler instructions and where obviously C# doesn’t dwell. I’m not familiar with this domain and I don’t score it here.
Test
I chose operations over a hierarchy tree. The test is synthetic. However, all of its parts (side by side element’s creation, up/down iteration and removing) can successfully exist in real logic. For both environments I chose standard solutions: C++ STL containers and streams and C# generics and IO. Both read the same operation sequences from files and calculated the same checksums.
My first results confused me. Surprisingly, C++ solution sucked. After some exploration I had found that C++ file stream was slower than C# one, because it possessed safe extraction from any sequence with special symbols. In C# I relied on some predefined special symbols sequence. So I replaced text files with binary files with predefined semantic. Also I emptied C# garbage collector to get the full element's removing equivalent.
All measurements were done side by side and alternately. So an idle/busy state of an operating system must influence to both applications equally.
Results
| Average spent time, sec | Resident memory, MB | |
| C# (.NET2.0) | 1,761 | 30,6 |
| C++(VC8.0) | 1,838 | 26,2 |
This situation is the nonsense. In any case C++ loses C#. Next endevour is to use Visual Studio 2003.
| Average spent time, sec | Resident memory, MB | |
| C# (.NET2.0) | 1,718 | 30,6 |
| C++(VC7.1) | 0,89 | 25,4 |
It's more likely. Searching Internet I've found next useful links:
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/4431bab9-7c6e-4907-8e85-66ac8798dbc6/
http://www.jenkinssoftware.com/raknet/forum/index.php?topic=2091.0
As expected applying additional compiler options doesn't help:
| Average spent time, sec | |
| C# (.NET2.0) | 1,757 |
| C++(VC8.0 + compiler options) | 1,785 |
So, try to guess, what's the real reason of this C++ slowing down?
What's in Linux.
| Average spent time, sec | Resident memory, MB | |
| C# (mono + .NET2.0) | 2,93 | 51,8 (mono) |
| C++ (wine + VC7.1) | 1,25 | 26,8 + 7,9 (wine) = 34,7 |
| C++(g++) | 1,45 | 13,4 |
Another nonsense. Bravo, ms guys! Your solution beats native one. You can if you want.
Conclusion
When performance can be the argument when you choose between C# and C++? In the term of common performance I think it's not the argument, even for engines. Only in solutions where logic routines (looped, real-time virtual processors ...) must out maximum performance C++ is the key, because it’s more flexible (for instance, libraries faster than standard STL exist – you can build your own framework) and managed environment features (type checking ...) must be avoided by definition.
In any case one private kludge can bring more performance issues than a programming environment at all.
