.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環境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的函數，需特別謹慎，否則將耗費大量系統資源。