.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，结果惊人的一致。

     .NET Framework是Microsoft为跨平台开发应用程序而创建的一个富 ......

>>返回讨论的主题