.NET Framework是Microsoft为跨平台开发应用程序而创建的一个富有革命性的平台。为了实现其跨平台开发的目标，.NET Framework采用了不同于传统的应用程序编译模式，例如：在VS2003/VS2005/VS2008编译.NET Framewrok所编写的代码时，不是立即创建操作系统特定的本机代码，而是把代码编译为Microsoft中间语言（Microsoft Intermediate Language，MSIL），这些代码不专用于任何一种操作系统，也不专用于C#；要执行应用程序，是Just-In-Time（JIT）编译器的任务，它把MSIL编译为专用于OS和目标机器结构的本机代码。
     这样，带来的好处是显而易见的，它使得Studio.NET这样的开发工具不仅可以开发PC桌面应用程序，而且还可以开发WinCE应用程序，未来还可以支持更多的应用平台；但是，一个硬币都有两面，我们还是要怀疑一下这种模式的应用效率。为此我们通过在VS2005 C#开发的调用COM组件的应用程序做了实验。
     实验使用英创EM9161嵌入式主板（主频200MHz）和ETA102数采模块采集外部10个通道电压。采用两种模式：
     （1）在C#应用程序里面直接编写采集AD的函数。因为ETA102数据采集模块直接与EM9161的精简ISA总线连接，通过英创的ISA总线进行采集控制。英创提供了ISA总线接口的COM组件，所以该直接用C#编写的函数将反复调用ISA COM组件，大略统计采集一次数据将调用COM组件函数50次左右。
     （2）用eVC编写采集AD的应用代码，然后将该代码统一打包成一个COM组件，在C#的应用程序直接调用该COM组件函数使用，也就是说，进行一次数据采集只调用一次COM组件函数。
     如上两种模式，实现的目的和功能完全一致，我们将数据采集的次数延长，比如采集几千次AD数据，然后统计所花费的时间，发现方式（1）所耗费的时间数倍于采用方式（2），我们得到一个简单结论，C#调用COM组件的效率较低，反复调用COM组件大量地消耗了系统资源和时间。为此，我们进行了简单的计算。为了计算的参照性，我们引用了eVC同样的应用程序执行数据采集所花费的时间作为参考时间。那么，可以这样认为：
     程序运行总时间 = 花费在实际数据采集的时间+COM组件消耗的时间+其它系统小开销
     其中，“其它系统小开销”在数据采集次数足够多的情况下，可以忽略不计，“花费在实际数据采集上的时间”采用eVC应用程序所得到的数据，那么，我们可以对方式（1）和（2）进行一个简单计算，实际结果是：方式（1）和方式（2）得到的调用一次COM组件应用函数所耗费的时间均是17us，结果惊人的一致。
 
实验硬件环境
英创EM9161工控主板+ETA102数采模块
CPU：32位ARM9（ARM926EJ-S内核）
主频：200MHz

软件
VS2005 C#

一次COM组件调用时间
17us

     根据上述实验，我们可以得到在.NET Framework环境C#应用程序开发中COM组件的调用效率原则：即COM组件功能本身的执行时间应大于17us，才可能保证C#应用程序具有较高的执行效率。例如在方式（1）中，每次ISA总线执行的时间只有0.5us，因此若在C#程序中通过反复进行ISA总线的COM组件调用，则实际代码效率就肯定很低；而在方式（2）中，采用专门的AD采集COM组件，可实现一次采集多个样点，每个样点的采集时间为45us，因此，若C#在调用该COM组件时，采用一次采集10个样点的策略，则可获得很高的代码效率。总之，为了保证使用C#等“高级”语言（其他的类似语言有.NET VB、LabView等）进行应用开发的时候具有合理的代码执行效率，对需反复大量调用COM组件函数应仔细了解COM组件函数的实际执行时间，对执行时间小于17us的函数，需特别谨慎，否则将耗费大量系统资源。