托管 C++ CodeModel 和其他 COM 对象与 C# 性能对比
我正在为 Visual Studio 2008 创建一个扩展，并且因为我不想为 C++ 编写自己的解析器（我不是受虐狂），所以我使用 VCCodeModel。
从这些 COM 对象中获取一个简单的字段比我正在执行的任何其他操作花费的时间要多几个数量级，并且由于我正在深入到非常大的 C++ 项目的方法级别，所以我在递归的最低级别上效率低下。
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)));
}
前面的代码将迭代项目基础级别的所有函数，将它们转换为 XML，然后保存它们。 XML 方法将调用 VCCodeFunction 内的多个字段，如名称、参数等。
为此，托管 C++ 是否比 C# 更快？ 我对托管 C++ 后端与 C# 的不同之处了解不够，但我的直觉会让我相信 C++ 中托管代码和非托管代码之间的“上下文切换”成本较少，但我错了吗？ 我认为使用 CodeModel 在 C++ 中的托管代码和非托管代码之间反复切换，速度明显变慢，所以我假设托管 C++ 会更快，是否正确？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
.NET 中的 COM 互操作层存在开销。 如果您要使用 C++，则可以将 COM 访问移至本机代码中，这将加快该部分代码的访问速度。
但是，如果您计划使用 C++/CLI，那么在某些时候您仍然会拥有本机>托管互操作。 在链中的某个位置，您将编组数据，尽管如果您可以将其移到这些循环之外，您可能会更快一些（如果您使递归 100% 原生，则互操作调用会少得多）。
话虽如此，VCCodeModel 并不是特别快 - 虽然我同意您通过 COM 互操作获得一些开销，但请注意您使用的分析器可能夸大了这一点。 如果您使用跟踪分析器，则尤其如此，因为在分析过程中您将在这些调用上花费比在实际发布运行期间更多的时间。 探查器并不完美，在这种情况下，您可能会因为探查器而得到不正确的结果。
我怀疑你的潜在速度增益不值得移植 - 尽管如果没有更多信息很难确定。
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.
与代码模型的速度相比，加载项/包语言的速度没什么。 编辑：好吧，也许我太过分了，但说真的，这里的第一句话是正确的。
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.
C++ 不太可能更快。
编写您自己的解析器可能执行更快。 当然，编写自己的解析器可能需要更长的时间。
C++ would be unlikely to be faster.
Writing your own parser might execute faster. Writing your own parser might take considerably longer, of course.