问个特菜的问题。在相同的软硬件环境下，将函数写在COM组件里和写在普通DLL里，哪个效率更高些？

Question

可否顺便说明一下理由？当然，有测试数据最好了。多谢指点。

Answer 1

写在DLL中
然后通过LoadLibrary,GetProcAddress...来调用
这样的做法效率应该比使用COM来得高

Answer 2

俺也觉得普通DLL高些。至少省略了COM读注册表的时间。还有COM是通用的（调用语言无关性），软件产品的特点通用的效率必然不如专用的高（菜鸟的看法）。嘿嘿

Answer 3

可是语言无关恰恰是COM的优点和设计目的所在，么有太大的可比性，毕竟应用范围有所不同。如果只是把COM作为DLL能够实现的效果来用，那DLL效率要高些吧...

Answer 4

我一直以为我在CSDN只能放分，没想到这里居然有得分的机会。
楼主，不要吝啬，给我点分吧。
其实是一样的了。
COM接口是通过DLL实现的，
但是如果你的COM组件包含在EXE内，就不一样了。这样的进程间调用通过“远程过程调用”
完成，效率就底得多。而且还涉及到参数在不同进程空间内的传递问题。
另：
读注册表确实需要时间，但是用户基本上不会感觉到的。

Answer 5

举个例子，给你一瓶汽水，你也可以对瓶吹，你也可以插根吸管（要多粗有多粗的）喝，有什么不同吗？
普通dll相当于对瓶吹，com相当于插根吸管喝，呵呵。

Answer 6

如果仅就函数本身的调用而言，应该是一样的（远程调用除外）。
但是由于COM在调用到函数前，有一系列的准备，所以直接调用效率高。

Answer 7

举个例子，给你一瓶汽水，你也可以对瓶吹，你也可以插根吸管（要多粗有多粗的）喝，有什么不同吗？
普通dll相当于对瓶吹，com相当于插根吸管喝，呵呵。
----这个例子俺理解不了，愚钝啊。总觉得COM的初始化慢点，以及接口（面向对象）不如DLL直接呢（面向过程）

Answer 8

如大家所言 多數情況下直接用DLL能得到更高的效率
但是某些特殊情況下可能COM/COM+組件更快一些 這要看具體實現
比如
黨一個組件建立了一個對象池 那麽第二個請求這一組件的CoCreateInstance就會直接從對象池中取得一個已創建好的對象指針 這樣比一個普通的LoadLibrary GetProcAddress也許更快

Answer 9

我的意思是说两者没区别啦，也不是，两者根本没有可比性，dll只是一种二进制镜像文件，com也可以是dll形式的，当得到接口指针（同一套间中）后，实际上得到的是一个函数指针的指针，和调用虚函数的情况一样，何谈什么性能损失？！
另外，有人说com库初始化会有性能损失，实际上这个操作在同套间的情况下根本没有什么性能损失，CoInitialize只是做一些当前线程相关的时间可以忽略不计的操作，至于注册表处理只会在组件激活时进行。com库的使用会有多大性能损失呢？那敢问一下，CRT库的使用有多大性能损失？答案是与业务逻辑相比，可以认为没有性能损失。