Preliminary: The caller is a native EXE that exposes a type of "plugin" architecture. It is designed to load a DLL (by name, specified as a command line arg). That DLL must be native, and export a specific function signature. The EXE is C++, which isn't too important since the EXE is a black box (cannot be modified/recompiled). The native DLL can meet the application needs by completely implementing the solution natively, in said DLL. However, a requirement is to allow the real work (thus turning the native DLL into a thin wrapper/gateway) to be coded in C#. This leads me to 3 options (if there are more, please share):
初步:调用者是一个本机EXE,它暴露了一种“插件”架构。它旨在加载DLL(按名称,指定为命令行arg)。该DLL必须是本机的,并导出特定的函数签名。 EXE是C ++,由于EXE是黑盒子(不能修改/重新编译),因此不太重要。本机DLL可以通过在所述DLL中完全实现解决方案来满足应用程序需求。但是,要求是允许实际工作(从而将本机DLL转换为薄包装器/网关)以C#编码。这导致我有3个选项(如果有更多,请分享):
- Native DLL loads a C++/Cli DLL that internally makes use of a C# class library
- Native DLL interacts with a C# COM object via CCW
- Native DLL hosts CLR and makes calls to C# assembly
Native DLL加载一个内部使用C#类库的C ++ / Cli DLL
本机DLL通过CCW与C#COM对象交互
本机DLL托管CLR并调用C#程序集
One more requirement is that not only does the native DLL need a way to send messages (call functions) on the C#, but the C# needs to be able to fire events/callback to the native DLL when certain extraordinary things occur (as opposed to shutting down and returning). Now this last thing I'm not sure how to handle in the 3rd option, but that is another question altogether.
还有一个要求是,本机DLL不仅需要一种在C#上发送消息(调用函数)的方法,而且C#需要能够在发生某些特殊事件时触发事件/回调到本机DLL(而不是关闭并返回)。现在这最后一件事我不知道如何处理第三个选项,但这是另一个问题。
So to the point: performance. Any info regarding those approaches (assuming they all meet the requirements)? From my investigation, my understanding is 2 would have more overhead than 1, but I'm not 100% confident, which is why I'm here. As for 3, I just don't have any info yet.
所以说到:性能。有关这些方法的任何信息(假设它们都满足要求)?根据我的调查,我的理解是2会比1更多的开销,但我不是100%自信,这就是为什么我在这里。至于3,我还没有任何信息。
So if anyone has dealt with these (or knows of another elegant option), please chime in.
因此,如果有人处理过这些(或知道另一个优雅的选项),请加入。
Thanks!
1 个解决方案
#1
I've done option 1 before, with reasonable success. I don't remember any significant performance implications, though my application wasn't terribly performance-intensive. It seems to me that if performance problems occur, a likely culprit might be the frequent, small native-to-managed transitions. Would it be possible to batch those at the C++/CLI layer?
我之前做过选项1,取得了合理的成功。我不记得任何重大的性能影响,尽管我的应用程序并不是非常严重的性能。在我看来,如果出现性能问题,可能的罪魁祸首可能是频繁的,小的本机到管理的转换。是否可以在C ++ / CLI层批量处理?
#1
I've done option 1 before, with reasonable success. I don't remember any significant performance implications, though my application wasn't terribly performance-intensive. It seems to me that if performance problems occur, a likely culprit might be the frequent, small native-to-managed transitions. Would it be possible to batch those at the C++/CLI layer?
我之前做过选项1,取得了合理的成功。我不记得任何重大的性能影响,尽管我的应用程序并不是非常严重的性能。在我看来,如果出现性能问题,可能的罪魁祸首可能是频繁的,小的本机到管理的转换。是否可以在C ++ / CLI层批量处理?