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

推荐订阅源

Google Online Security Blog
Google Online Security Blog
博客园_首页
酷 壳 – CoolShell
酷 壳 – CoolShell
Jina AI
Jina AI
博客园 - Franky
大猫的无限游戏
大猫的无限游戏
Hugging Face - Blog
Hugging Face - Blog
博客园 - 司徒正美
V
V2EX
雷峰网
雷峰网
云风的 BLOG
云风的 BLOG
V
Visual Studio Blog
F
Full Disclosure
Y
Y Combinator Blog
V
V2EX - 技术
Attack and Defense Labs
Attack and Defense Labs
S
Security @ Cisco Blogs
Schneier on Security
Schneier on Security
Microsoft Azure Blog
Microsoft Azure Blog
SecWiki News
SecWiki News
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
The GitHub Blog
The GitHub Blog
量子位
PCI Perspectives
PCI Perspectives
S
Secure Thoughts
D
Darknet – Hacking Tools, Hacker News & Cyber Security
AWS News Blog
AWS News Blog
Blog — PlanetScale
Blog — PlanetScale
爱范儿
爱范儿
K
Kaspersky official blog
B
Blog
A
Arctic Wolf
Hacker News: Ask HN
Hacker News: Ask HN
L
LangChain Blog
T
Tor Project blog
P
Privacy & Cybersecurity Law Blog
Recent Announcements
Recent Announcements
宝玉的分享
宝玉的分享
The Register - Security
The Register - Security
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
L
Lohrmann on Cybersecurity
D
Docker
A
About on SuperTechFans
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Google DeepMind News
Google DeepMind News
The Last Watchdog
The Last Watchdog
S
Security Affairs
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
P
Privacy International News Feed
Simon Willison's Weblog
Simon Willison's Weblog

博客园 - 风前絮~~

回来啦 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优化了委托的性能后这种情况可以改善,灵活是需要牺牲性能的。

相关代码