惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

A
About on SuperTechFans
Y
Y Combinator Blog
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Microsoft Security Blog
Microsoft Security Blog
aimingoo的专栏
aimingoo的专栏
I
InfoQ
C
Check Point Blog
IT之家
IT之家
MyScale Blog
MyScale Blog
Apple Machine Learning Research
Apple Machine Learning Research
Vercel News
Vercel News
Last Week in AI
Last Week in AI
GbyAI
GbyAI
P
Proofpoint News Feed
量子位
Stack Overflow Blog
Stack Overflow Blog
Microsoft Azure Blog
Microsoft Azure Blog
月光博客
月光博客
阮一峰的网络日志
阮一峰的网络日志
人人都是产品经理
人人都是产品经理
B
Blog
T
The Blog of Author Tim Ferriss
H
Help Net Security
云风的 BLOG
云风的 BLOG

博客园 - 风前絮~~

回来啦 Rainbow分页解决方案 FTB2.0和CuteEditor的一些问题 testFTB2.0 testCuteEditor 看看MS内部对.NET的使用情况... base想到... 多个Main函数的应用程序 - 风前絮~~ - 博客园 伟大架构师的秘密 权限管理越来越复杂 ASP.NET跨应用程序进行登录的解决 Server的Transfer和Response的Redirect FreeTextBox实现机制 FreeTextBox的ToolbarButton整理 Testing vs Debugger 稍不留神产生代码垃圾 C#中"is" vs "as" - 风前絮~~ .NET建议使用的大小写命名原则 using的几种用法
再比较动态调用代码
风前絮~~ · 2004-09-14 · via 博客园 - 风前絮~~

       上次在MSDN网站看到一个比较动态调用代码的文章,用到的例子似乎比较复杂,为计算一个复杂多项式子而将其中部分割开,动态形成代码段来被循环调用。详细看.NET下几种动态生成代码方式比较。今天看到微软C#团队的Eric Gunnerson写的另外一篇关于动态调用代码性能的比较文章,为了说明结果和计算的准确性,减少由于函数复杂而受编译优化的影响,他使用了一个极为简单的例子:
输入一个参数,然后返回这个参数加一,这么简单的函数,优化和没有优化的代码应该不会有差别的了。


而对比方面,除了上次那几种外,还加了代理方式调用来进行比较。
1. 直接调用

int value = processor.Process(i);

2. 用反射机制,Type.InvokeMember()调用。

3. 通过一个接口

4. 通过一个委托Delegate

5. 也通过反射机制建立委托再动态调用

6. 元编程方式

对于2和5由于使用反射机制,不可避免需要建立中间的临时对象去传递参数,将参数和返回值装箱等操作,因此花费了大量的机器时间。

下面是运行的某次结果(循环100000次):


结论:
1.直接调用速度最快是肯定的。
2.接口调用比元编程速度快,而元编程又比委托方式快,但微软相信Whidbey会极大优化委托调用方式,从而使它接近接口调用的水平。
3.直接用Type的反射机制是速度最慢的,比用反射机制建立委托来动态调用还慢。
4.直接使用委托不够灵活,有时候需要用反射机制建立委托来调用,但会减低性能,希望Whidbey优化了委托的性能后这种情况可以改善,灵活是需要牺牲性能的。

相关代码