.NET程序性能的基本要领
2014-05-14 22:18 by 老赵, 19067 visits说起Roslyn大家肯定都已经有所耳闻了，这是下一代C#和VB.NET的编译器实现。Roslyn使用纯托管代码开发，但性能超过之前使用C++编写的原生实现。Bill Chiles是Roslyn的PM（程序经理，Program Manager），他最近写了一篇文章叫做《Essential Performance Facts and .NET Framework Tips》，其中总结了几条经验，目前是个CodePlex上的PDF文件，以后可能会发布在MSDN上。
他在文章里谈到以下几点：
- 不要进行过早优化。程序员有了一定经验以后，往往会对性能有所直觉，但也要避免盲目优化。
- 没有评测，便是猜测。例如，有的时候重复计算都比使用哈希表进行缓存来的快。
- 好工具很重要。这里他推荐了PerfView，这是个微软发布的免费工具，将来分析某些案例时我可能也会用到这个工具。
- 性能的关键，在于内存分配。凭直觉可能很多人会觉得编译器是一个CPU密集型的场景，但实际上它终究还是个IO密集型的程序。
- 其他一些细节。例如，对于字典的内存开销要有一些概念，还有例如我每次面试都会问到的class与struct的区别等等。
第4点值得多说几句。对于托管环境来说，GC对于性能的影响重大。假如一段程序写的不够GC友好，让GC发生的多，尤其是那种Stop-the-World GC，这对性能的影响远胜某些“多花了几条拷贝指令”之类的“探索”。而且很多时候，用户眼中的“性能”在于程序的“响应程度（responsiveness）”，一旦GC暂停了所有的线程，程序便很容易发生卡顿，这甚至不是通过简单评测程序性能能够体现出来的。
相较于Java平台来说，.NET已经是个相对GC友好的运行环境了。其中最重要的方面之一便是自定义值类型，即struct。struct让程序员进行一定程度上可控的内存分配，避免在堆上产生对象。而在Java中，只有几种原生类型是值类型，它们还不能包含成员。要知道在Java里无法使用一个未装箱的int值作为一个字典的键，这对一个.NET程序员来说可能很难想象，但事实便是如此。
当然，Java似乎已经有打算作这方面的改进，但离真正可用还遥遥无期。目前Java只能通过一些如逃逸分析的手段，发现某个对象不会被共享到堆上，于是便将其分配在栈上，避免对GC产生压力。
不过.NET提供再多对GC友好的功能，也抵不过开发人员的误用。Bill的文章里举了一些常见案例，这些其实都是每个.NET开发人员必须了解的基础。最后那个例子颇为有趣，他谈到，对于性能敏感的地方，有时候都要避免LINQ或Lambda。因为使用Lambda构造匿名函数时，编译器会产生闭包，因为所谓闭包，便是一个用来保存上下文的，分配在堆上的对象。此外，如List<T>的迭代器被有意实现为struct，但使用通用的LINQ接口，则会被转化为IEnumerable<T>和IEnumerator<T>，进而产生装箱。
无独有偶，不久前@连城404在新浪微博上说到：
按照Michael的建议把HiveTableScan关键路径上的FP风格的代码换成while循环加可复用的mutable对象，扫表性能提升40%。”，这其实也正和这次的话题密切相关。
半夜不清醒，四则运算都算错了…发上条微博的时候实际上是提升了100%多点。之后继续蚊子腿上刮肉，不光是while循环，关键路径上的模式匹配代码也能刮出油水（例如省掉Array.unapplySeq调用开销）。目前使用LazySimpleSerDe的普通CVS表扫表性能提到2.2x，RCFile加上列剪枝可以提到3x。#Spark SQL#
而Alan Perlis同样说过：
Lisp programmers know the value of everything but the cost of nothing.
可谓颇为有趣。常用的FP手段的确会带来性能开销，这是事实，不过假如你现在立即得出“不要用FP”或“还好没学FP”这样的结论，那我也只能用怜悯的眼光看着你了。
最后，您有减少内存分配，优化GC这方面的实践吗？不妨联系我吧，有机会我也会谈一下我在这方面的一些技巧和案例的。
很是期待下文啊，实际开发中对于拆箱装箱还比较注意，但是闭包这类就很随意了，即使有些方法提供了参数可以不用闭包也因为要强转一次而作罢。
而实际开发中往往一个数据库索引，缓存带来的收益比去研究GC带来的收益大的多，所以上至领导下到小兵谁还会去关注GC呢
就我的实际经验来讲，我"觉得"序列化(WCF、Memcache)对GC的压力是最大的