领导力大挑战
在实施Scrum项目的过程中，Scrum Master的角色是相当关键的，因为他是团队的推动者。本文围绕什么是仆人式领导、仆人式领导的起源、如何将领导力传达给团队、Scrum Master作为仆人式领导者的角色展开叙述，同时重点阐述仆人式领导者应有的基本内外特征。
新闻
该内容已经被标记书签！
标记书签错误，请重试！
讨论：泛型是否会对性能产生负面影响
作者 赵劼 发布于 2009年5月30日
正值端午传统节日，在国内知名的.NET技术社区博客园中进行了一场较为激烈的讨论。讨论话题围绕：.NET中的泛型是否会影响性能。
飞林沙的一篇文章《从dynamic到特性误用》引起了这场讨论。在这片文章中，飞林沙指出C# 4.0新增的dynamic关键字会对程序性能的影响，呼吁大家仅在合适的时候使用dynamic新特性。可能是由于社区中对于C# 4.0的新特性还不太关注，这个问题本身的反响不大。反而是文章所引发的一个周边话题引起了网友的兴趣。
在文章的结尾，飞林沙认为太多开发人员并没有了解新特性的优劣就盲目追逐，并举出他所认为的一个泛型错误做法：
……我看到有人在代码中使用List<Object>而不是ArrayList，我不明白这种做法除了降低性能之外还有什么好处……
文章发表不久，便有网友对此观点产生质疑，认为“泛型是生成新的类型，拿来的效率影响之说”，不过也有网友表示“.NET的泛型会略微影响效率，跟C++略有些不同”。在Jeffrey Zhao发表了一篇性能比较文章之后，围绕这个话题的讨论便由此展开。
Jeffrey Zhao的文章《泛型真的会降低性能吗？》使用代码来统计常用操作所消耗的时间，试图发现泛型容器对性能的影响。除了.NET类库中经典的ArrayList和List<T>类型之外，他还编写了最简单的MyArrayList和MyList<T>两个类型，目的是避免其它任何实现方面的细节对性能的影响。对于长度为100的容器，各执行30万次操作的结果如下表所示：
| 使用for进行下标遍历 | 使用foreach进行遍历 | |
|---|---|---|
| MyArrayList | 2,398ms | 21,367ms |
| MyList<Object> | 2,285ms | 3,463ms |
| ArrayList | 2,282ms | 5,187ms |
| List<Object> | 2,302ms | 2,989ms |
根据实验结果，Jeffrey Zhao得出了以下结论：
……泛型的MyList性能甚至略比MyArrayList有所提高。当然测试的结果其实是互有胜负，但是事实上，MyList的获胜的次数甚至还略有领先……从结果上已经可以看出，泛型并不会影响性能，而List<T>的性能也不比ArrayList要差……
Jeffrey Zhao同时呼吁“在有泛型支持的情况下，尽量使用泛型容器。例如使用List<Object>而不是ArrayList”：
……除了“性能”之外，老赵的还有其他一些理由。例如使用List<Object>的话就可以使用框架内部所定义的各种有用的辅助方法（要知道在.NET框架中，现在几乎都是在针对IEnumerable<T>进行开发）；而我们平时写程序时，也可以统一的针对泛型编程，如IList<T>，IEnumerable<T>，不必考虑List或Enumerable等非泛型元素。
Jeffrey Zhao的测试结果得到了大部分网友的承认，不过也有部分网友对这个实验的部分做法有所质疑。如开源框架NBear的创始人Teddy Ma认为MyArrayList的foreach操作慢的原因在于非泛型的IEnumerator内部对于数组使用Array.GetValue(Int32)来获取对象，而泛型的IEnumerator<T>则直接使用数组下标进行访问：
……如果都用for而不是foreach，我想应该非泛型略快一点点。
对此，Jeffrey Zhao回应道：
……我测试的都是平时的常用操作，黑盒测试，没有故意去走某个特别慢的路径。……看来内部实现的造成问题，可惜我们平时都是用这个做法，因为是框架自带的。
为什么总是说泛型性能会差一些？测试结果都摆在这里了。根据测试结果，就算是下标访问，泛型也不差。……所以结论还是不变，能够用List<Object>就不要用ArrayList。
稍后又有网友引用了国外网友Rico Mariani的文章回复中总结的观点，认为ArrayList比List<Object>性能差的原因在于：
- ArrayList中使用了大量的虚方法，.NET框架设计团队不反对我们继承ArrayList实现新的集合类型。这种做法也影响了JIT对方法的内联。
- ArrayList的遍历器实现较为复杂，会构造大量的Enumerator对象。而在.NET 2.0中新设计的List<T>类型简化了这部分代码，获得了较高的性能。
至此，大家基本已经达成共识，ArrayList性能较差是由于内部实现逻辑的影响，在实际开发过程中使用List<Object>能够获得更好的性能。不过，还是有一些网友“普遍认为”，抛开泛型对值类型装箱/拆箱的性能优化，纯粹的泛型容器性能还是会略低于非泛性的Object容器。不过，Jeffrey Zhao新发表的一篇文章似乎从根本上推翻了这个看法。
在《从汇编入手，探究泛型的性能问题》一文中，Jeffrey Zhao使用WinDbg查看了MyArrayList和MyList<Object>的下标get方法，在JIT之后所生成的汇编代码，并加以详细的分析和对比。比较的结果发现，两者除了几个地址不同之外，在执行时所经过的指令几乎完全相同，以此有力地证明了“泛型并不会影响程序性能”。
在问题的讨论过程中也产生了一些额外的话题，例如究竟应该使用for和下标访问，还是foreach来遍历一个容器，还有一个应用程序是否应该在这样的地方追求性能提升。
您的看法是什么呢？
赵劼 网名为老赵，洋名Jeffrey Zhao，写有技术博客“老赵点滴”。关注前沿技术，并致力于开源社区与微软平台的组合优化。
理论=实际
发表人
Yang Bob
发表于
Re: 理论=实际
发表人
zhang rocky
发表于
Re: 理论=实际
发表人
xing xing
发表于
Re: 理论=实际
发表人
Zhao Jeffrey
发表于
Re: 理论=实际
发表人
xing xing
发表于
Re: 理论=实际
发表人
Zhao Jeffrey
发表于
可以直接使用ForEach方法
发表人
梁 中华
发表于
Re: 可以直接使用ForEach方法
发表人
Zhao Jeffrey
发表于
-
我想说这个30万操作调用在实际的应用中的场景,一次密集执行30万的情景多还是累计执行30万次多,如果真的需要这么密集的操作,那么是不是又说明了其他问题呢?另外如果时间上处于分散状态,那么快慢根本可以忽略,这篇文章我认为属于"理论"研究,有点脱离实际的场景.
-
"另外如果时间上处于分散状态,那么快慢根本可以忽略,这篇文章我认为属于"理论"研究,有点脱离实际的场景. "阁下说的很对，但是，这篇article的题目是“泛型是否会对性能产生负面影响”，就泛型讨论泛型，这是一个工程中的小细节，而不是整个工程的Bus
-
题目跟内容就已经有出入了,就算.net泛型 会对性能产生负面影响 也不能代表其他语言实现的泛型会对性能产生负面影响.
再则,如果产生影响,只能说是.net 挂羊头卖狗肉了.
infoq这篇文章是不是有点标题党了 -
的确这是专讲.NET的泛型。不过看到摘要已经说清了是.NET社区，因此就没有太多注意。下次一定改正，希望继续支持，谢谢！
至于泛型的性能，其实是因为Java的泛型只是编译器的语法糖，对于性能没有提升。
而.NET对于性能来说，由于避免了装箱/拆箱/类型转换等操作，因此性能的提升是很明显的（尤其是避免了装箱/拆箱）。
于是有人的意见就是，有得必有失，是否List<Object>性能就会略差于直接使用Object呢？这篇文章讨论的其实是这个问题。</object> -
为什么直接用foreach呢？可以直接使用ForEach方法，这个方法可以避免每次循环调用时的枚举变量，速度应该更快些的
-
其实ForEach方法内部就是一个for循环，通过下标访问List<T>，性能和试验里的for循环性能是一样的。
foreach其实是提供了更好的语义，虽然性能会略有降低。</t> -
我觉得如果一个语言里如果要用泛型的话,这个泛型的具体化版本实现应该由编译程序来完成,而不是程序执行时动态实现,如果不是由编译器来完成这具体化的工作,那么可能只是称呼大于其实际内容了
-
在.NET中，泛型实际由JIT完成，其实也是由编译器生成的新类型。
在Java中，JVM本身不支持范型，Java代码中的泛型由Java语言编译器转化为Cast操作，实际效果和自己写存储Object然后进行Cast是一样的。
8 条回复
关注此讨论 回复