Managed C++ vs C# Performance for CodeModel and other COM Objects

Question

I am creating an extension for Visual Studio 2008, and because I didn't want to write my own parser for C++ (I'm not masochistic) I am using VCCodeModel.

Getting a simple field from these COM objects takes orders of magnitude more time than any of the other operations I am doing, and since I am drilling down to the method level of very large C++ projects I have this inefficiency at the lowest levels of my recursion.

   vcCodeBaseFunctions = ((Microsoft.VisualStudio.VCCodeModel.VCCodeElements)
              (vcCM.Functions));
   int i = 0;
   for (i = 1; i <= vcCodeBaseFunctions.Count; i++)
   {
     if (vcCodeBaseFunctions.Item(i).Kind == vsCMElement.vsCMElementFunction)
          parent.AppendChild(MethodWrapper.VCCodeFunctionToXML(
                          (VCCodeFunction)vcCodeBaseFunctions.Item(i)));
   }

The preceding code would iterate through all of the functions at the base level of a project, convert them to XML and then save them. The XML method would call multiple fields inside the VCCodeFunction like name, parameters, etc.

Is managed C++ faster than C# for this purpose? I have an inadequate understanding of how the back end of managed C++ is different than C#, but my intuition would lead me to believe that there is less of a "context switch" cost between managed and unmanaged code in C++, but am I wrong? I am getting a good bit of slowdown from what I believe is switching repeatedly between managed and unmanaged code in C++ using CodeModel, so am I correct in assuming that managed C++ would be faster?

Answer 1

The add-in/package language speed is nothing compared to the speed of the code model. Edit: ok, maybe I went overboard, but seriously, the first sentence here is correct.

Answer 2

C++ would be unlikely to be faster.

Writing your own parser might execute faster. Writing your own parser might take considerably longer, of course.

Answer 3

There is an overhead with the COM interop layer in .NET. If you were to use C++, you could move your COM access into native code, which would speed up that section of the code access.

However, you're still going to have native->managed interop at some point, if you're planning to use C++/CLI. Somewhere in the chain, you'll be marshalling data across, although you may be a bit faster if you can move this outside of these loops (if you make your recursion 100% native, you'd have far fewer interop calls).

That being said, the VCCodeModel is not particularly fast - Although I agree that your getting some overhead with the COM interop, be aware that the profiler you're using may be exaggerating this. This is particularly true if you're using a tracing profiler, as you're going to be spending more time in those calls during profiling than during an actual release run. Profilers aren't perfect, and this may be a case where you're getting skewed results due to your profiler.

I suspect that your potential speed gains would not merit a port - although it would be difficult to know for sure without more information.