西西软件园多重安全检测下载网站、值得信赖的软件下载站!
软件
软件
文章
搜索
鐢熸椿鏈嶅姟
鏀粯瀹濋挶鍖�(Alipay)V10.2.53.7000 瀹夊崜鐗�鏀粯瀹濋挶鍖�(Alipay)V10.2.53.7000 瀹夊崜鐗�
鐧惧害鍦板浘瀵艰埅2022V15.12.10 瀹夊崜鎵嬫満鐗�鐧惧害鍦板浘瀵艰埅2022V15.12.10 瀹夊崜鎵嬫満鐗�
鎵嬫満娣樺疂瀹㈡埛绔痸10.8.40瀹樻柟鏈€鏂扮増鎵嬫満娣樺疂瀹㈡埛绔痸10.8.40瀹樻柟鏈€鏂扮増
鐣呴€旂綉鎵嬫満瀹㈡埛绔痸5.6.9 瀹樻柟鏈€鏂扮増鐣呴€旂綉鎵嬫満瀹㈡埛绔痸5.6.9 瀹樻柟鏈€鏂扮増
鍗冭亰鐭ヨ瘑鏈嶅姟appv4.5.1瀹樻柟鐗�鍗冭亰鐭ヨ瘑鏈嶅姟appv4.5.1瀹樻柟鐗�
褰遍煶鎾斁
p2psearcher瀹夊崜鐗�7.3  鎵嬫満鐗�p2psearcher瀹夊崜鐗�7.3 鎵嬫満鐗�
閰风嫍闊充箰2022瀹樻柟鐗圴11.0.8 瀹樻柟瀹夊崜鐗�閰风嫍闊充箰2022瀹樻柟鐗圴11.0.8 瀹樻柟瀹夊崜鐗�
鐖卞鑹烘墜鏈虹増v13.1.0鐖卞鑹烘墜鏈虹増v13.1.0
鐧惧害褰遍煶7.13.0 瀹樻柟鏈€鏂扮増鐧惧害褰遍煶7.13.0 瀹樻柟鏈€鏂扮増
褰遍煶鍏堥攱v6.9.0 瀹夊崜鎵嬫満鐗�褰遍煶鍏堥攱v6.9.0 瀹夊崜鎵嬫満鐗�
闃呰宸ュ叿
鑵捐鍔ㄦ极V9.11.5 瀹夊崜鐗�鑵捐鍔ㄦ极V9.11.5 瀹夊崜鐗�
涔︽棗灏忚鍏嶈垂鐗堟湰v11.5.5.153 瀹樻柟鏈€鏂扮増涔︽棗灏忚鍏嶈垂鐗堟湰v11.5.5.153 瀹樻柟鏈€鏂扮増
QQ闃呰鍣╝ppV7.7.1.910 瀹樻柟鏈€鏂扮増QQ闃呰鍣╝ppV7.7.1.910 瀹樻柟鏈€鏂扮増
鎳掍汉鐣呭惉鍚功appv7.1.5 瀹樻柟瀹夊崜鐗�鎳掍汉鐣呭惉鍚功appv7.1.5 瀹樻柟瀹夊崜鐗�
璧风偣璇讳功app鏂扮増鏈�20227.9.186 瀹夊崜鐗�璧风偣璇讳功app鏂扮増鏈�20227.9.186 瀹夊崜鐗�
閲戣瀺鐞嗚储
骞冲畨璇佸埜瀹塭鐞嗚储V9.1.0.1 瀹樻柟瀹夊崜鐗�骞冲畨璇佸埜瀹塭鐞嗚储V9.1.0.1 瀹樻柟瀹夊崜鐗�
娴烽€氳瘉鍒告墜鏈虹増(e娴烽€氳储)8.71 瀹樻柟瀹夊崜鐗�娴烽€氳瘉鍒告墜鏈虹増(e娴烽€氳储)8.71 瀹樻柟瀹夊崜鐗�
涓滄捣璇佸埜涓滄捣鐞嗚储4.0.5 瀹夊崜鐗�涓滄捣璇佸埜涓滄捣鐞嗚储4.0.5 瀹夊崜鐗�
涓摱璇佸埜绉诲姩鐞嗚储杞欢6.02.010 瀹樻柟瀹夊崜鐗�涓摱璇佸埜绉诲姩鐞嗚储杞欢6.02.010 瀹樻柟瀹夊崜鐗�
鍗庨緳璇佸埜灏忛噾鎵嬫満鐞嗚储杞欢3.2.4 瀹夊崜鐗�鍗庨緳璇佸埜灏忛噾鎵嬫満鐞嗚储杞欢3.2.4 瀹夊崜鐗�
鎵嬫満閾惰
绂忓缓鍐滄潙淇$敤绀炬墜鏈洪摱琛屽鎴风2.3.4 瀹夊崜鐗�绂忓缓鍐滄潙淇$敤绀炬墜鏈洪摱琛屽鎴风2.3.4 瀹夊崜鐗�
鏄撳埗浣滆棰戝壀杈慳pp4.1.16瀹夊崜鐗�鏄撳埗浣滆棰戝壀杈慳pp4.1.16瀹夊崜鐗�
鏀粯瀹濋挶鍖�(Alipay)V10.2.53.7000 瀹夊崜鐗�鏀粯瀹濋挶鍖�(Alipay)V10.2.53.7000 瀹夊崜鐗�
涓浗宸ュ晢閾惰鎵嬫満閾惰appV7.0.1.2.5 瀹夊崜鐗�涓浗宸ュ晢閾惰鎵嬫満閾惰appV7.0.1.2.5 瀹夊崜鐗�
涓浗閾惰鎵嬫満閾惰瀹㈡埛绔�7.2.5 瀹樻柟瀹夊崜鐗�涓浗閾惰鎵嬫満閾惰瀹㈡埛绔�7.2.5 瀹樻柟瀹夊崜鐗�
浼戦棽鐩婃櫤
鑵捐鐚庨奔杈句汉鎵嬫満鐗圴2.3.0.0 瀹樻柟瀹夊崜鐗�鑵捐鐚庨奔杈句汉鎵嬫満鐗圴2.3.0.0 瀹樻柟瀹夊崜鐗�
鍔茶垶鍥㈠畼鏂规鐗堟墜娓竩1.2.1瀹樻柟鐗�鍔茶垶鍥㈠畼鏂规鐗堟墜娓竩1.2.1瀹樻柟鐗�
楗ラタ椴ㄩ奔杩涘寲鏃犻檺閽荤煶鐗坴7.8.0.0瀹夊崜鐗�楗ラタ椴ㄩ奔杩涘寲鏃犻檺閽荤煶鐗坴7.8.0.0瀹夊崜鐗�
妞嶇墿澶ф垬鍍靛案鍏ㄦ槑鏄�1.0.91 瀹夊崜鐗�妞嶇墿澶ф垬鍍靛案鍏ㄦ槑鏄�1.0.91 瀹夊崜鐗�
鍔ㄤ綔灏勫嚮
鍦颁笅鍩庣獊鍑昏€卋t鐗�1.6.3 瀹樻柟鐗�鍦颁笅鍩庣獊鍑昏€卋t鐗�1.6.3 瀹樻柟鐗�
瑁呯敳鑱旂洘1.325.157 瀹夊崜鐗�瑁呯敳鑱旂洘1.325.157 瀹夊崜鐗�
鍦f枟澹槦鐭㈤泦缁搗4.2.1 瀹夊崜鐗�鍦f枟澹槦鐭㈤泦缁搗4.2.1 瀹夊崜鐗�
閬ぉ3D鎵嬫父1.0.9瀹夊崜鐗�閬ぉ3D鎵嬫父1.0.9瀹夊崜鐗�
濉旈槻娓告垙
瀹夊崜妞嶇墿澶ф垬鍍靛案2榛戞殫鏃朵唬淇敼鐗圴1.9.5 鏈€鏂扮増瀹夊崜妞嶇墿澶ф垬鍍靛案2榛戞殫鏃朵唬淇敼鐗圴1.9.5 鏈€鏂扮増
涔辨枟瑗挎父2v1.0.150瀹夊崜鐗�涔辨枟瑗挎父2v1.0.150瀹夊崜鐗�
淇濆崼钀濆崪3鏃犻檺閽荤煶鏈€鏂扮増v2.0.0.1 瀹夊崜鐗�淇濆崼钀濆崪3鏃犻檺閽荤煶鏈€鏂扮増v2.0.0.1 瀹夊崜鐗�
鍙h鑻遍泟鍗曟満鐗�1.2.0 瀹夊崜鐗�鍙h鑻遍泟鍗曟満鐗�1.2.0 瀹夊崜鐗�
灏忓皬鍐涘洟瀹夊崜鐗�2.7.4 鏃犻檺閲戝竵淇敼鐗�灏忓皬鍐涘洟瀹夊崜鐗�2.7.4 鏃犻檺閲戝竵淇敼鐗�
璧涜溅绔炴妧
鐧诲北璧涜溅2鎵嬫父1.47.1  瀹夊崜鐗�鐧诲北璧涜溅2鎵嬫父1.47.1 瀹夊崜鐗�
涓€璧锋潵椋炶溅瀹夊崜鐗坴2.9.14 鏈€鏂扮増涓€璧锋潵椋炶溅瀹夊崜鐗坴2.9.14 鏈€鏂扮増
璺戣窇鍗′竵杞︽墜鏈虹増瀹樻柟鏈€鏂扮増v1.16.2 瀹夊崜鐗�璺戣窇鍗′竵杞︽墜鏈虹増瀹樻柟鏈€鏂扮増v1.16.2 瀹夊崜鐗�
鐙傞噹椋欒溅8鏋侀€熷噷浜戜慨鏀圭増(鍏嶆暟鎹寘)v4.6.0j 閲戝竵鏃犻檺鐗�鐙傞噹椋欒溅8鏋侀€熷噷浜戜慨鏀圭増(鍏嶆暟鎹寘)v4.6.0j 閲戝竵鏃犻檺鐗�
鐧句箰鍗冪偖鎹曢奔2021鏈€鏂扮増5.78 瀹夊崜鐗�鐧句箰鍗冪偖鎹曢奔2021鏈€鏂扮増5.78 瀹夊崜鐗�
瑙掕壊鎵紨
姊﹀够鍓戣垶鑰呭彉鎬佺増1.0.1.2瀹夊崜鐗�姊﹀够鍓戣垶鑰呭彉鎬佺増1.0.1.2瀹夊崜鐗�
浠欏浼犺ro澶嶅叴瀹夊崜鐗�1.20.3鏈€鏂扮増浠欏浼犺ro澶嶅叴瀹夊崜鐗�1.20.3鏈€鏂扮増
姊﹀够璇涗粰鎵嬫父鐗�1.3.6 瀹樻柟瀹夊崜鐗�姊﹀够璇涗粰鎵嬫父鐗�1.3.6 瀹樻柟瀹夊崜鐗�
鐜嬭€呰崳鑰€V3.72.1.1 瀹夊崜鏈€鏂板畼鏂圭増鐜嬭€呰崳鑰€V3.72.1.1 瀹夊崜鏈€鏂板畼鏂圭増
璋佸灏忚溅寮烘墜鏈虹増v1.0.49 瀹夊崜鐗�璋佸灏忚溅寮烘墜鏈虹増v1.0.49 瀹夊崜鐗�
绯荤粺杞欢
mac纾佺洏鍒嗗尯宸ュ叿(Paragon Camptune X)V10.8.12瀹樻柟鏈€鏂扮増mac纾佺洏鍒嗗尯宸ュ叿(Paragon Camptune X)V10.8.12瀹樻柟鏈€鏂扮増
鑻规灉鎿嶄綔绯荤粺MACOSX 10.9.4 Mavericks瀹屽叏鍏嶈垂鐗�鑻规灉鎿嶄綔绯荤粺MACOSX 10.9.4 Mavericks瀹屽叏鍏嶈垂鐗�
Rar瑙e帇鍒╁櫒mac鐗坴1.4 瀹樻柟鍏嶈垂鐗�Rar瑙e帇鍒╁櫒mac鐗坴1.4 瀹樻柟鍏嶈垂鐗�
Mac瀹夊崜妯℃嫙鍣�(ARC Welder)v1.0 瀹樻柟鏈€鏂扮増Mac瀹夊崜妯℃嫙鍣�(ARC Welder)v1.0 瀹樻柟鏈€鏂扮増
Charles for MacV3.9.3瀹樻柟鐗�Charles for MacV3.9.3瀹樻柟鐗�
缃戠粶宸ュ叿
鎼滅嫍娴忚鍣╩ac鐗坴5.2 瀹樻柟姝e紡鐗�鎼滅嫍娴忚鍣╩ac鐗坴5.2 瀹樻柟姝e紡鐗�
閿愭嵎瀹㈡埛绔痬ac鐗圴1.33瀹樻柟鏈€鏂扮増閿愭嵎瀹㈡埛绔痬ac鐗圴1.33瀹樻柟鏈€鏂扮増
蹇墮mac鐗坴1.3.2 瀹樻柟姝e紡鐗�蹇墮mac鐗坴1.3.2 瀹樻柟姝e紡鐗�
鏋佺偣浜旂瑪Mac鐗�7.13姝e紡鐗�鏋佺偣浜旂瑪Mac鐗�7.13姝e紡鐗�
濯掍綋宸ュ叿
Apple Logic Pro xV10.3.2Apple Logic Pro xV10.3.2
Adobe Premiere Pro CC 2017 mac鐗坴11.0.0 涓枃鐗�Adobe Premiere Pro CC 2017 mac鐗坴11.0.0 涓枃鐗�
鍗冨崈闈欏惉Mac鐗圴9.1.1 瀹樻柟鏈€鏂扮増鍗冨崈闈欏惉Mac鐗圴9.1.1 瀹樻柟鏈€鏂扮増
Mac缃戠粶鐩存挱杞欢(MacTV)v0.121 瀹樻柟鏈€鏂扮増Mac缃戠粶鐩存挱杞欢(MacTV)v0.121 瀹樻柟鏈€鏂扮増
Adobe Fireworks CS6 Mac鐗圕S6瀹樻柟绠€浣撲腑鏂囩増Adobe Fireworks CS6 Mac鐗圕S6瀹樻柟绠€浣撲腑鏂囩増
鍥惧舰鍥惧儚
AutoCAD2015 mac涓枃鐗堟湰v1.0 瀹樻柟姝e紡鐗�AutoCAD2015 mac涓枃鐗堟湰v1.0 瀹樻柟姝e紡鐗�
Adobe Photoshop cs6 mac鐗坴13.0.3 瀹樻柟涓枃鐗�Adobe Photoshop cs6 mac鐗坴13.0.3 瀹樻柟涓枃鐗�
Mac鐭㈤噺缁樺浘杞欢(Sketch mac)v3.3.2 涓枃鐗�Mac鐭㈤噺缁樺浘杞欢(Sketch mac)v3.3.2 涓枃鐗�
Adobe After Effects cs6 mac鐗坴1.0涓枃鐗�Adobe After Effects cs6 mac鐗坴1.0涓枃鐗�
Adobe InDesign cs6 mac1.0 瀹樻柟涓枃鐗�Adobe InDesign cs6 mac1.0 瀹樻柟涓枃鐗�
搴旂敤杞欢
Mac鐗堝揩鎾�1.1.26 瀹樻柟姝e紡鐗圼dmg]Mac鐗堝揩鎾�1.1.26 瀹樻柟姝e紡鐗圼dmg]
Mac璇诲啓NTFS(Paragon NTFS for Mac)12.1.62 瀹樻柟姝e紡鐗�Mac璇诲啓NTFS(Paragon NTFS for Mac)12.1.62 瀹樻柟姝e紡鐗�
杩呴浄10 for macv3.4.1.4368 瀹樻柟鏈€鏂扮増杩呴浄10 for macv3.4.1.4368 瀹樻柟鏈€鏂扮増
Mac涓嬫渶寮哄ぇ鐨勭郴缁熸竻鐞嗗伐鍏�(CleanMyMac for mac)v3.1.1 姝e紡鐗�Mac涓嬫渶寮哄ぇ鐨勭郴缁熸竻鐞嗗伐鍏�(CleanMyMac for mac)v3.1.1 姝e紡鐗�
鑻规灉BootCamp5.1.5640 瀹樻柟鏈€鏂扮増鑻规灉BootCamp5.1.5640 瀹樻柟鏈€鏂扮増

首页编程开发C#.NET → .Net中各种不同的对象创建方式的速度差异(四)

.Net中各种不同的对象创建方式的速度差异(四)

相关文章发表评论 来源:tonyhuang时间:2010/2/24 14:46:05字体大小:A-A+

作者:佚名点击:336评论:0次标签: 对象

  • 类型:浏览辅助大小:2KB语言:中文 评分:7.2
  • 标签:
立即下载

在这片文章中,我们暂时放一放Activator.CreateInstance(Type)和Activator.CreateInstance<T>()之间的性能差异,去探索一下,为什么使用泛型约束的速度和CreateInstance<T>()差不多(用屁股都能猜到应该是直接调用了CreateInstance<T>())。

 


首先我们写一个小程序来验证我们的猜想:

1 using System;
2
3 namespace GenericNew
4 {
5 public class Program
6 {
7 public static void Main(string[] args)
8 {
9 CreateInstance<Program>();
10 new Program();
11 }
12
13 public static T CreateInstance<T>() where T: new()
14 {
15 return new T();
16 }
17 }
18 }
 

编译了以后用reflector来查看编译的结果:

1 public static T CreateInstance<T>() where T: new()
2 {
3 return new T();
4 }
5
 

看起来没有什么问题啊,跟写的时候一样美妙,也没有见到System.Activator.CreateInstance<T>()的踪影。

那么,让我们切换到msil模式看看:

1 .method public hidebysig static !!T CreateInstance<.ctor T>() cil managed
2 {
3 .maxstack 2
4 .locals init (
5 [0] !!T local,
6 [1] !!T local2)
7 L_0000: nop
8 L_0001: ldloca.s local2
9 L_0003: initobj !!T
10 L_0009: ldloc.1
11 L_000a: box !!T
12 L_000f: brfalse.s L_001c
13 L_0011: ldloca.s local2
14 L_0013: initobj !!T
15 L_0019: ldloc.1
16 L_001a: br.s L_0021
17 L_001c: call !!0 [mscorlib]System.Activator::CreateInstance<!!T>()
18 L_0021: stloc.0
19 L_0022: br.s L_0024
20 L_0024: ldloc.0
21 L_0025: ret
22 }
 

恩,发现[mscorlib]System.Activator::CreateInstance<!!T>()了,通过分析这段代码,我们会发现,其实ms对于这个的性能还是做了一定的优化的,这段代码:

 

试图采用值类型的初始化方法初始化对象,并对该对象进行装箱操作
装箱失败的情况下,调用System.Activator.CreateInstance<T>()来创建对象
 

最后再返回创建好的对象。

那么是不是.net本来就是通过这种方式来创建对象的呢?

我们来对比一下new Program()这条语句的编译结果:

1 newobj instance void GenericNew.Program::.ctor()

 

那么为什么c#编译器没有采用这个指令来创建泛型类的实例呢?

我们需要参考一下msdn上对于newobj的用法的定义:

http://msdn.microsoft.com/en-us/library/system.reflection.emit.opcodes.newobj(VS.85).aspx

在这里,我们看到,newobj指令的使用方法是 newobj <ctor>

也就是说,它的参数是构造器,而非类型本身; 原因就在于,.Net允许有不同参数的构造器存在,只有指定了构造器,clr才知道要使用哪个构造器来初始化对象。

而,对于一个泛型类,在编译器是无法知道它的泛型参数的构造器信息的,自然就没有办法使用newobj指令了。

 


这就是事实的真相,在下一篇文章中,我们将去探究,事实的终极真相。

posted @ 2010-02-24 12:58 TonyHuang 阅读(14) | 评论 (0) | 编辑

.Net中各种不同的对象创建方式的速度差异(三)
本文章为本人个人博客相应文章的镜像:

原文地址: http://www.greatony.com/index.php/2010/02/20/speed-of-object-creation-in-dotnet-iii/

 

从前面的文章,我们发现以下两点有趣的东西:

 

使用System.Activator的非泛型方法比使用泛型方法快很多(超过200%)
使用泛型约束和new关键字创建的速度几乎和System.Activator的泛型方法的一样
 

在这篇文章里,我将会这两个问题做一个进一步的探究,我使用的工具就是鼎鼎大名的.Net反编译工具:Reflector,欢迎读者跟我一起探讨造成这个现象的原因。

第一段 从System.Activator.CreateInstance(Type)开始

我们先用Reflector打开.Net Framework 3.5中的mscorlib.dll,看看这里面,微软是怎么实现的。

首先看看System.Activator.CreateInstance(Type),它直接调用了System.Activator.CreateInstance(Type, Boolean),代码如下

1 public static object CreateInstance(Type type)
2 {
3 return CreateInstance(type, false);
4 }
 

那么这个CreateInstance(Type, Boolean)的实现,是这样的:

1 public static object CreateInstance(Type type, bool nonPublic)
2 {
3 if (type == null)
4 {
5 throw new ArgumentNullException("type");
6 }
7 RuntimeType underlyingSystemType = type.UnderlyingSystemType as RuntimeType;
8 if (underlyingSystemType == null)
9 {
10 throw new ArgumentException(Environment.GetResourceString("Arg_MustBeType"), "type");
11 }
12 return underlyingSystemType.CreateInstanceImpl(!nonPublic);
13 }
14
 

将这段代码简化一下,就是:

1 public static object CreateInstance(Type type, bool nonPublic)
2 {
3 RuntimeType underlyingSystemType = type.UnderlyingSystemType as RuntimeType;
4 return underlyingSystemType.CreateInstanceImpl(!nonPublic);
5 }
6
 

在RuntimeType的CreateInstanceImpl(bool isPublic)中,直接调用了CreateInstanceImpl(bool isPublic, bool skipVisibilityCheck, bool fillCache),这个函数的实现非常有意思,我先把代码贴出来:

1 internal object CreateInstanceImpl(bool publicOnly, bool skipVisibilityChecks, bool fillCache)
2 {
3 RuntimeTypeHandle typeHandle = this.TypeHandle;
4 ActivatorCache cache = s_ActivatorCache;
5 if (cache != null)
6 {
7 ActivatorCacheEntry entry = cache.GetEntry(this);
8 if (entry != null)
9 {
10 if ((publicOnly && (entry.m_ctor != null)) && ((entry.m_hCtorMethodHandle.GetAttributes() & MethodAttributes.MemberAccessMask) != MethodAttributes.Public))
11 {
12 throw new MissingMethodException(Environment.GetResourceString("Arg_NoDefCTor"));
13 }
14 object obj2 = typeHandle.Allocate();
15 if (entry.m_ctor != null)
16 {
17 if (!skipVisibilityChecks && entry.m_bNeedSecurityCheck)
18 {
19 MethodBase.PerformSecurityCheck(obj2, entry.m_hCtorMethodHandle, this.TypeHandle.Value, 0x10000000);
20 }
21 try
22 {
23 entry.m_ctor(obj2);
24 }
25 catch (Exception exception)
26 {
27 throw new TargetInvocationException(exception);
28 }
29 }
30 return obj2;
31 }
32 }
33 return this.CreateInstanceSlow(publicOnly, fillCache);
34 }
35
 

看起来非常复杂,其实他的实现也也就实现了一个缓存机制:

 

检查缓存中是否存在这个构造器的委托,如果有,就调用自己的typeHandler的Allocate()方法分配内存,然后调用构造器的委托初始化对象
如果没有缓存,就调用CreateInstanceSlow(bool isPublic, bool fillCache)创建对象,并填充缓存
 

好吧继续再看看这个CreateInstanceSlow里面干了什么事情。

照例先贴代码吧:

1 private object CreateInstanceSlow(bool publicOnly, bool fillCache)
2 {
3 RuntimeMethodHandle emptyHandle = RuntimeMethodHandle.EmptyHandle;
4 bool bNeedSecurityCheck = true;
5 bool canBeCached = false;
6 bool noCheck = false;
7 this.CreateInstanceCheckThis();
8 if (!fillCache)
9 {
10 noCheck = true;
11 }
12 object obj2 = RuntimeTypeHandle.CreateInstance(this, publicOnly, noCheck, ref canBeCached, ref emptyHandle, ref bNeedSecurityCheck);
13 if (canBeCached && fillCache)
14 {
15 ActivatorCache cache = s_ActivatorCache;
16 if (cache == null)
17 {
18 cache = new ActivatorCache();
19 Thread.MemoryBarrier();
20 s_ActivatorCache = cache;
21 }
22 ActivatorCacheEntry ace = new ActivatorCacheEntry(this, emptyHandle, bNeedSecurityCheck);
23 Thread.MemoryBarrier();
24 cache.SetEntry(ace);
25 }
26 return obj2;
27 }
28
 

这个函数写的很复杂,其实实现的东西很简单,其一是调用RuntimeTypeHandler.CreateInstance方法创建对象,然后再填充缓存,以加快下次创建对象的速度。

好了,我们现在已经非常接近事实的真相了。让我们从另外一个角度出发,看看CreateInstance<T>()干了什么事情。

第二段 从System.Activator.CreateInstance<T>()开始

这里,我们先看看他的实现:

1 public static T CreateInstance<T>()
2 {
3 bool bNeedSecurityCheck = true;
4 bool canBeCached = false;
5 RuntimeMethodHandle emptyHandle = RuntimeMethodHandle.EmptyHandle;
6 return (T) RuntimeTypeHandle.CreateInstance(typeof(T) as RuntimeType, true, true, ref canBeCached, ref emptyHandle, ref bNeedSecurityCheck);
7 }
8
 

我们忽然就看到了我们熟悉的身影:RuntimeTypeHandler.CreateInstance方法,终于殊途同归啊。。。

也就是说,System.Activator.CreateInstance<T>()相当于调用了CreateInstanceSlow方法(但是没有缓存机制),这应该就是CreateInstance<T>比CreateInstance(Type)慢的主要原因,我们回顾一下这两个方法的时间消耗:

System.Activator.CreateInstance(Type):

 

缓存机制时间消耗
RuntimeTypeHandler.Allocate()内存分配的时间消耗
调用构造器委托初始化数据的时间消耗
 

这里不考虑缓存失败,调用CreateInstanceSlow的情况,因为这个只会发生一次。

System.Activator.CreateInstance(Type):

 

调用RuntimeTypeHandler.CreateInstance的时间消耗
 

在下一篇文章中,我会对这两个函数的性能差异做进一步的分析

相关评论

阅读本文后您有什么感想? 已有人给出评价!

  • 8 喜欢喜欢
  • 3 顶
  • 1 难过难过
  • 5 囧
  • 3 围观围观
  • 2 无聊无聊

热门评论

最新评论

发表评论 查看所有评论(0)

昵称:
表情: 高兴 可 汗 我不要 害羞 好 下下下 送花 屎 亲亲
字数: 0/500 (您的评论需要经过审核才能显示)