VSTO加载项与VBA性能

Question

如果您要编写功能相同的程序，我很好奇两者的性能比较。我正在开发一个项目，我开始认为，考虑到我需要在VBA中执行的比较函数的数量，加法可能更合适。

Answer 1

取决于这些计划的作用以及他们如何做。

VSTO /.net比VBA更快，并允许您编写在多个线程上运行的代码。但Excel是COM，最终所有东西都需要进入STA（单线程单元）管道，托管（.net）代码通过COM Interop与COM对话，即它通过主互操作程序集与Excel通信， 比“原生”VBA慢。

换句话说：

• 您的程序执行了大量处理，并且很少有电子表格读/写，请转到VSTO。
• 您的程序会进行大量的电子表格交互，请转到VBA。电子表格交互几乎是VBA可以做的最慢的事情，但使用VSTO进行交互会更加痛苦，因为所有内容都需要从托管代码封送到COM。

Best可以是一个混合解决方案：在VBA中公开用户定义的函数，并将VBA代码调用到引用的COM可见.net DLL中，该DLL执行实际计算，甚至不使用Excel互操作程序集。

编写良好的VBA代码也可以胜过同等的VSTO代码。

  

考虑到我需要在VBA中执行的比较函数量，我开始认为插件可能更合适。

您也可以在VBA中编写Excel加载项。涉及的技术越少，他们彼此交谈的次数就越少;在一天结束时，您可以根据您的要求，环境和经验，对多种事物的重视程度进行平衡：

• 效果 - 哪种解决方案表现最佳？
• 可维护性 - 哪种解决方案最容易维护？
• 部署 - 哪种解决方案最易于更新和部署？
• 源代码管理 - Visual Studio挂钩 Team Frustration Foundation Server 和Git; VBE可以使用Rubberduck（我的一个小宠物项目）做Git，但是最新版本仍然是测试版并且有点不稳定（虽然它是开源的，所以如果你知道C＃你可以贡献并帮助稳定它）。
• 单元测试 - Visual Studio可以轻松编写和运行单元测试; VBE可以使用Rubberduck执行相同的操作，但是如果没有VBE插件，则必须使用临时测试，或者启用对VBIDE API的编程访问并使用基于VBA的单元测试框架。