优化增强您的Visual C++应用程序

核心提示：为什么 dllexport 不能始终适用使用 __declspec(dllexport) 有它自己的缺陷，当您有两个映射(DLL 或 exe)都为托管映射，优化增强您的Visual C++应用程序(5)，但通过 dllexport 而不是通过 #using 公开功能时，dllexport 的问题就会暴露，他的大部分工作

为什么 dllexport 不能始终适用

使用 __declspec(dllexport) 有它自己的缺陷。当您有两个映射(DLL 或 exe)都为托管映射，但通过 dllexport 而不是通过 #using 公开功能时，dllexport 的问题就会暴露。因为 dllexport 是一个本机构造，所以每次使用 __declspec(dllexport) 跨 DLL 边界调用时，都会先引发从托管到本机的转换，再引发从本机到托管的转换。这样就难以获得很好的性能。

解决这种性能问题的选择很有限。没有简单的“开关”可以立刻让 __declspec(dllexport) 成为对托管代码没有相关 thunk 的构造。推荐的修复办法是将导出的功能包装在一个托管类型(引用或值类/结构)中，导入程序再通过导出 DLL 上的“#using”访问该类型，从而直接访问导出 DLL 中的功能。通过这种更改，当从托管客户端调用这段托管代码时就不需要进行转换。图 8 中对此做了说明，其中 A 部分显示了与使用 __declspec(dllexport) 相关的成本，B 部分显示了使用 #using 和将函数包装在 .NET 类型中所带来的优化。这种方法的一个潜在问题是导出 DLL 的非托管导入程序不能对 DLL 的功能进行 __declspec(dllimport)。这在进行更改之前应该加以考虑。

图 8 降低 Thunk 成本

图 8 的 A 部分显示了使用 __declspec(dllexport) 将托管函数公开给托管代码的转换路径。在 B 部分中，该函数被包装成托管类型，并使用 #using 来访问该函数。与 A 部分中的过程相比，其结果是省去了成本很高的 thunk。

小结

Visual Studio .NET 2002 引入了带有 Visual C++ 的 .NET Framework 已有很长的时间。C++ 使得编程人员编写高性能托管代码具有很大的灵活性，而且都是按 C++ 编程人员很自然的方式工作的。有许多语言可用于进行 .NET 编程;如果您想获得最大的性能，则 Visual C++ 是显而易见的选择。

Kang Su Gatlin 是 Microsoft Visual C++ 团队的程序经理，他的大部分工作时间都在尝试寻找可让程序运行更快的系统方式。在到 Microsoft 工作之前，他从事高性能和网格计算。