从 VB.net 调用本机 c++ dll 与从本机 .exe 调用运行时运行速度较慢

Question

我在本机 C++ (Visual C++ 2010) 中有一些代码来处理一些 GB 的文件。我将其编译为 .exe，大约需要 8 分钟。但是我需要从 Visual Basic .net 接口调用它，所以我把它放在一个 .dll 中并创建了一个 c++/cli 包装类来调用我在本机 dll 中的代码。托管代码和本机 dll 之间的唯一交互是调用启动处理的函数。令我惊讶的是，处理所需的时间几乎是 .exe 方式的两倍。我不是真正的 VB.net 专家，所以也许有一些设置或一些我不知道的东西要看。欢迎任何想法。提前致谢。

Answer 1

几个想法：

• 也许您使用 Release 配置构建了 .exe，但 .dll 设置为 Debug。您有时会看到发布版本和调试版本之间存在很大差异，优化的代码会产生巨大的差异。

• 如果您的 VB.net 除了调用 C++ 代码之外还执行其他操作，那么它可能会在您的 .dll 消耗的内容之上增加 CPU 负载。在 VB.net 端进行的任何类型的后台处理都可以解释这种差异。要将苹果与苹果进行比较，您应该有一个命令行 VB.net 应用程序，不带 GUI，并且只有一行调用 dll 函数。

• 如果上述方法没有帮助，我建议您创建一个本地 C++ 应用程序，该应用程序链接到同一个 DLL，并将其与本地 exe 版本进行比较。如果 C++ 和 DLL 版本的性能与 C++ 独立 exe 相同，那么 VB.net 端肯定存在消耗额外 CPU 的东西。另一方面，如果从本机 C++ 调用 DLL 也很慢，那么您应该寻找 exe 与 dll 的构建过程的差异，或 exe 与 dll 模式的宏/条件编译的差异。

祝你好运。

Answer 2

C++/CLI 包装器真的只是调用 DLL 函数，还是它自己加载 DLL，然后继续使用并由 .NET 管理？本机过程是获得自己的线程，还是在 .NET 的上下文中创建线程？我的直觉是 .NET 正在做一些不必要的事情来管理对象、DLL 或线程的生命周期。

因此，我的建议是添加一个事件来指示 DLL 正在完成它正在做的任何事情，从本机 DLL 启动一个新线程来运行该过程，并立即返回事件句柄。让您的 .NET 在适当的地方等待该句柄。

Answer 3

不太明白为什么从 DotNet 端调用的本机 dll 可以使处理时间加倍，除非你能提供更多细节。

但是，如果本机 exe 版本按预期运行，您可以从 DotNet 将本机 exe 作为后台进程运行，通过命令行传递 api 参数。您甚至可以将 exe 的控制台输出重定向到基于 DotNet 的 GUI。

Answer 4

这很奇怪。我会查看任务管理器中存在的所有列并比较两个进程（工作集大小、页面错误......）。然后我会查看性能监视器并查看缓存管理器的值。最后但并非最不重要的一点是，您可以尝试只从文件中读取而不是写入来查看时间花在了哪里。

Answer 5

.NET 框架在从其“托管”代码到本机或“非托管”代码的通信中产生了一些开销。 See here for some background.

因此，您在性能方面所看到的就是我所期望的一般情况。如果原生 DLL 做更多的工作，我预计通信开销（效率损失）的百分比会更低。