在我的公司,我们正在评估是否要从一个应用程序切换到另一个应用程序并且我有一些性能问题(这可能是无意义的......)我已经阅读了一些COM文章,我最清楚的是它与语言无关,但性能呢?
我们通过c#API使用第三方电网解算器,我们并不完全满意。 (使用API和COM一样吗?)
竞争对手都使用COM通信。
由于我们将给予程序的使用将是一个随机模拟框架,是否值得使用COM通信?它会非常慢吗?
我根本没有这方面的经验,我想要一些亮点。
提前致谢
答案 0 :(得分:0)
进行COM通信时基本上有两种可能性:1)进程内,2)进程外。
如果您想获得最高性能,那么您确实希望使用进程内COM(您的代码将在与客户端代码相同的过程中运行,因此不会涉及序列化或“编组”)。在这种情况下,实际上没有任何“通信”层。 COM是一个非常简单的二元合约。这里描述了:The layout of a COM object
有关v-table性能的更多信息,请访问:Virtual method table
请注意,进程内COM存在一些细微之处,尤其是the threading model。即使在进程中,您也要确保选择适合您的客户端/调用代码的线程模型。因此,在本文的“混合模型开发”一章中,您需要“直接访问”,而不是“编组”(在表中)。
答案 1 :(得分:0)
组件供应商通常会支持COM接口,因为这使得他们的产品可以在更多的运行时环境中使用。包括C ++,Delphi或任何脚本语言等语言。而C#,.NET框架对COM互操作有很好的支持,它将看起来像本机C#接口。确保您还没有使用COM,只是不知道它。您可以从部署说明中获得提示,COM组件通常需要清单或安装程序。
第二个考虑因素是COM通常是产品的广告界面,这些产品已经存在很长时间,10年或更长时间。这可能是通用的“网格求解器”类型的产品。产品稳定,十年内没有新的铃声和口哨声。这是您需要注意的事项,您通常无法获得对此类产品的支持,因为供应商不再需要程序员来处理该产品。当您更换产品所依赖的核心库时,获得良好支持始终很重要。
当你遇到性能问题时,支持尤为重要。您可以自己解决这些问题并不多,您真的希望能够与供应商合作以解决这些问题。
如果源是api层开销,那么COM肯定不是针对性能问题的神奇解决方案。如果解算器是一个单独的过程,那么可能就是这种情况,这种互操作是昂贵的。您可以在Taskmgr.exe,进程选项卡中轻松看到的内容,当您运行应用程序时,您会看到另一个EXE弹出窗口。无论如何,COM不可避免地包含从托管代码到非托管代码的一个重大缺陷。它通常非常快,但如果api调用非常精细,那么它可以加起来。