码迷,mamicode.com
首页 > 其他好文 > 详细

五、CLR加载程序集代码时,JIT编译器对性能的产生的影响

时间:2018-02-01 19:20:57      阅读:146      评论:0      收藏:0      [点我收藏+]

标签:nop   必须   调用   .com   查找   bubuko   方法   结构   studio   

1、CLR首次加载代码造成的性能损失     

 四、CLR执行程序集中代码介绍了CLR在首次执行一个类的时,会初始化一个内部结构,然后当目标方法被首次调用时,JITComplier函数(JIT编译器)会验证IL代码并将IL代码编译成本地CPU指令并存储到动态内存中,这意味着一旦应用程序终止,编译好的代码也会被丢弃,所以,当再次运行应用程序,或者同时启动应用程序的两个实例(使用两个不同的操作系统的进程),JIT编译器必须再次将IL编译成本机指令.对于某些应用程序,这可能会增加内存的负担.

相比之下,本机(native)应用程序的只读代码页可由应用程序正在运行的所有实例共享.

 

2、CLR首次加载代码造成的性能损失的严重程度

对于大多数应用程序,JIT编译造成的损失并不严重,大多数应用程序都在反复的调用相同的方法。应用程序运行期间,这些方法只会对性能造成一次性的影响.除此之外,在方法内部花费的时间可能比花在首次调用方法,JIT编译和优化IL所花费的时间更多.

 

3、CLR加载代码时JIT编译器进行的代码优化

CLR首次加载程序集代码时,JIT将IL编译成本地代码时,会对其进行代码优化,这类似与非托管C++编译器的后端所做的事情.这可能也会花费加多的时间生成优化代码.

 

技术分享图片

(1)、编译器开关/optimize和/debug对代码的影响

/optimize开关:

C#编译器生成的未优化IL代码,将包含许多NOP(空操作)指令,还将包含许多跳转到下一行代码的分支指令.Visual Stdio利用这些指令在调试提供"编辑并继续"功能.另外,利用这些额外的指令,还可在控制流程指令(比如for,while,do,if,else,try,catch和finally)上设置断点,使代码更容易调试.相反,如果生成优化的IL代码,C#编译器会删除多余的NOP和分支指令,而在控制流程被优化之后,代码就不能再调试器中进行单步调试了。代码若在调试器中执行,一些函数求值可能无法进行.但是,优化过的IL代码变得更小,结果EXE/DLL文件也更小.

 

/debug(+/full/pdbonly)开关:

编译器会生成Program Database(PDB)文件,PDB文件帮助调试器查找局部变量并将IL指令映射到源代码.

/debug:full开关告诉JIT编译器你打算调试程序集,那么JIT编译器会记录每条IL指令所生成的本机代码.这样依赖,就可利用Visual Studio的“即时”调试功能,将调试器连接到正在运行的进程,并方便地对源代码进行调试.

不打开/debug:full开关,JIT编译器默认不记录IL与本机代码的联系,这使JIT编译器运行的稍快,占用内存也稍少.如果进程用Visual Stdio的“即时”调试功能,会强迫JIT编译器记录IL与本机代码的联系(无论编译器的开关设置是什么)除非在Visual Stdio中关闭了"在模块加载时取消JIT优化(权限托管)"操作步骤如下:

工具-选项-调试

技术分享图片

 

(2)、Visual Stdio中新建C#项目时,编译器开关的默认设置

通过VS新建项目时,项目的调试(Debug)配置的是/optimize-和debug:full开关(IL代码和本地代码均未优化-方便调试),而"发布"(Release)配置置顶的是/optimize+和/debug:pdbpnly开关(IL代码和本地代码均优化-文件变小,占用内存小)

 

五、CLR加载程序集代码时,JIT编译器对性能的产生的影响

标签:nop   必须   调用   .com   查找   bubuko   方法   结构   studio   

原文地址:https://www.cnblogs.com/GreenLeaves/p/8400567.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!