博客园_FireLong-编程呓语

Silverlight战略失败, .NET平台进入衰退期,微软帝国轰然倒塌的导火索

2010-10-28T16:30:00Z

刚看到新闻：《微软Silverlight战略发生转移回归HTML5》：http://news.cnblogs.com/n/79114/ ，与我前面对微软的战略失败预测不谋而合。下面将之前的文章做些许修改，分析分析微软.NET战略的失败，以及微软帝国倒塌的征兆。

1. Silverlight的放弃是微软互联网战略的失败，微软帝国轰然倒塌的导火索。　随着Silverlight的失败，微软.NET平台彻底进入衰退期，WPF、WCF、WF、ASP.NET等技术将逐步宣告失败，随着iPad和Chrome平板电脑的上市，Windows将失守个人电脑市场，微软帝国倒塌的命运不可避免。

2.微软的首席架构师Ray Ozzie跳槽了，Bill Gates撒钱去了，执掌微软的巴尔默是个Top Sales，崩管怎么Top，终究是个sales。我在微软中国的好多朋友最近纷纷跳槽的也很多。泰坦尼克沉默的时候，最好的选择是跳离，而不是傻呆在船上。

3. 微软已是昨日黄花，对移动互联网反应迟钝，还以为用户都爬在Windows上呢？根本不知道用户都去户外移动去了。

4. .NET这个花拳绣腿的东西担当不了重任，微软当初为.NET描述的蓝图没一个实现，反倒被apple和google逐步实现

5. 微软在自己的黄金发展期，在.NET上整了十二年了，没有用.NET开发出一个拿得上台面的产品(自己没有，业界也没有)。你能相信.NET会在未来微软走下坡路的时候，土鸡变凤凰吗？看看iOS和Android短短一年在业界的飞速进展，微软.NET组的精英们还有脸见人吗?

6. 微软还在残缺抱守二十年前的卖软件拷贝的战略。而google和apple的崛起一再告诉我们产业已经进入了服务和体验阶段。

7. 在世界上所有IDE都免费的时代，就微软还在赚IDE的钱。开发人员是你的衣食父母，他们给Windows开发软件是在帮你微软，你还要在他们身上宰一刀！

8. 微软还在沿用二十年前老旧的开发过程，3年出一个版本，你当用户是傻子啊？你用3年前琢磨的东西来满足现在的我？

9. 微软是个最忽视用互体验的公司，就一个安装过程，就把大多数用户吓跑了。人家番茄花园一个人做了半年，就横扫装机界。微软号称几千人，几年搞的Windows......

10. 微软从来不把用户当人，又是环境变量，又是注册表，又是分区，又是命令行？......普通用户谁管你这些？看看苹果的iPhone，iPad，Mac，哪有这样复杂的?

11. Firelong已于上周跳槽到一家互联网公司做一分支事业部经理（管人，事，产品的那种），主做移动互联网。今后我会在这里和大家分享一些移动互联网，产品设计方面的话题。

本文链接

C#会重蹈覆辙吗？系列之4：华而不实的C#析构器

2010-08-30T15:21:00Z

前段时间去鸟国出差，颠倒黑白，碌碌无为，疏于写博，请大家理解。下面继续前贴7月《C与C++社区混战，C#会重蹈覆辙吗？》的讨论。这次要谈的是C#的析构器的问题。这是C#中非常华而不实的一个设计，不必要，且常常误导很多C#er，且是.NET性能问题的常见陷阱地带。下面逐项讨论：

１.C#析构器是一个丑陋的语法糖

C#析构器（即Destructor）本质上是对Finalize方法的一个override。既然是对Finalize方法的override，那就大大方方让程序员去override 根类Object的Finalize方法好了。可是，C#设计师们首先搞了一个析构器，接着又在编译器里面把父类的Finalize方法隐藏掉（你去override的时候，告诉你父类没有Finalize方法）。但是编译完后，在IL代码中又告诉你override了父类中的Finalize方法，而你写的析构器却不翼而飞！

我在编程语言历史上看到很多语法糖，有些语法糖华丽，有些语法糖冗赘。但是还从没见过如此弯弯绕的语法糖！

2. C#析构器偏离了析构器原有的意思

析构器自在各编程语言中造始，便有以下两大基本含义：

(a) 回收对象内部开销的动态内存以及各种资源

(b) 回收具有确定性时刻，比如delete对象时，或者栈cleanup时。

可是C#将Finalize强扭成析构器后，彻底丢失掉前面两大基本含义，既无法回收动态内存，又无法确定时刻调用（只能等GC在猴年马月想起来才调用）。而只用于回收资源（而即便连这个任务也完成得很差，参见3.C#析构器不能完成其设计的初衷）。这使得很多沿用以前析构器概念的程序员经常犯如下错误，比如：

class MyClass {

object field;

~MyClass() { field=null; } //既不必要，也严重损伤性能

}

class MyClass {

object field;

~MyClass() { GC.Collect(); } //既不必要，也严重、严重损伤性能

}

3. C#析构器不能完成其设计的初衷

前面说过C#析构器主要用于释放对象的资源（非托管资源），而非内存。

但很不幸，对于C#析构器这个唯一的任务，它却不能很好地胜任。因为C#析构器（也就是Finalize方法）是由GC调用的，而GC只会在猴年马月想起来才调用（回收对象之前的一轮回收），往往延误了对象资源的释放——而对象资源是非常昂贵的。　如果真的这样来做的话，项目会倒大霉——比如我们以前的一个项目，有部分程序员在析构器中释放一些native内存，最后导致内存暴涨——用户抱怨下来，最后一调试发现原来都是在析构器惹得祸——这些析构器半天没有被GC调用！

实际上，C#设计者在后来意识到这个问题了，于是又推出来一个Dispose方法（即Dispose模式）来让用户显式释放资源。然后又推荐程序员在Dispose里面GC.SuppressFinalize(). 即屏蔽析构器。　

既然Dispose能将事情（确定性地释放非托管资源）做好，析构器如此没用，当初设计它干吗？这是再典型不过的多余设计了！

4. C#析构器会带来严重的性能障碍

a) C#析构器会将对象的代标记（Generation）拖大，使得对象更难以被GC回收，给GC造成更大性能负担。

b) 析构器本身释放资源较晚，造成资源紧张，影响系统性能。

c) 析构器执行需要一个单独的线程开销，该线程的执行（必须时间很短）需要其他线程停止，也是一个性能负担。

这也是为什么C#推荐实现Dispose，不推荐实现析构器的原因。因为析构器的性能代价太大。可能中小项目的开发人员感受不到这一点，但我相信做过大型项目的朋友，对C#析构器的性能问题会有非常深的体会。

综上，C#析构器是C#设计师们纯粹为了炫耀自己华丽语法糖、而不小心又失了手艺、一个拙劣的设计。

[ Update: ] 听从网友的建议，把文章中“脑抽型、臭脚、sucks”等“骂街”的话删除掉了。写这些“骂街”的话实在是昨晚文章写到深处，肝火旺盛，想到某些言论，情不自禁而已。并非我就是“泼妇”，今天一看自己昨晚的言论确实火力太猛，接受大家的意见，改正语言风格，希望下面坚持“技术讨论不骂街“的原则。如果我有时候情不自禁做不到，希望大家监督指点，我会及时改过自新，重新做人:)

本文链接

扒扒腾讯的“抄袭皮＋忽悠皮”

2010-07-29T18:19:00Z

最近由于计算机世界《狗日的腾讯》一文刊出，激起了很多QQ粉的满腔热血。这也倒罢了，QQ粉本来就是中国的弱智脑残一代。可在技术社区中，还看到一大堆为腾讯叫好，打抱不平的。这就令人奇怪了。要说搞技术的，智商一般都还可以。firelong实在看不下去，写文章一篇，扒扒腾讯的皮。

先来扒腾讯的“抄袭”皮：

1. 腾讯缺乏引导人类科技创新的动力和实力，只知道跟在别人后面抄袭。微软：让人人桌上有一台电脑。Google：整合全球信息，使人人皆可访问并从中受益。Apple：改变了音乐（iPad+iTunes），改变了手机(iPhone)，还要改变消费电子（iPad）。Amazon：改变了人类的阅读。Facebook，改变了人类的沟通。腾讯的愿景动力是什么？“一站式在线生活服务？扯吧，直接说“一站式抢钱服务”多好。

2.腾讯对世界、对中国也没有技术贡献。作为一个“300亿美金的著名互联网公司”，腾讯给世界、给中国做了贡献了什么技术？操作系统？编程语言？数据库？Web服务器？哪怕一个开源的工具软件，腾讯有吗？　反倒偷偷改改开源软件的事频频出现（http://d1.it168.com/show/29893.html），让中国IT技术人在世人面前蒙羞——你好歹是号称世界上第三大互联网公司啊。腾讯享用了很多大公司、小公司、无数开源IT技术人的贡献，却只知道自己闷头赚钱，从不贡献。

3. 千万别把在骗中国科委而申请的专利（http://www.soopat.net/Patent/201010111636）叫技术创新，中国的绝大多数专利跟技术创新无关。

4. 腾讯也没有商业模式上的创新。腾讯只不过是看谁赚钱就去抢谁饭碗而已，自从有了QQ开始，从来没听说过QQ给中国IT领域贡献了什么样创新的商业模式？“决不做第一个吃螃蟹的人”就是腾讯骨子里的抄袭生存哲学。

5. 不要口口声声“用户体验”，“用户体验”，腾讯的“用户体验”只不过是琢磨怎么从用户兜里忽悠钱，同时还让用户大喊爽而已。一点没有技术含量。跟创新也无关系。

6. 腾讯给中国IT技术界树立的坏榜样：不创新，不贡献，埋头抄袭是王道！

再来扒腾讯的“忽悠”皮：

有的朋友可能会说，创新算什么，能赚这么多钱的商业模式本来伟大的商业模式。首先，我要说，赚很多钱！＝伟大。脑白金给史玉柱赚了很多钱，脑白金伟大吗？大家看看脑白金赚的都是什么人的钱？忽悠老头老太太！大家来看看腾讯赚的都是什么人的钱:

1. 腾讯2009年第四季度财务分析　参考来源：http://tech.qq.com/a/20100317/000347.htm

互联网增值服务收入比上一季度增长8.6%，达到人民币28.471亿元，占第四季度总收入的77.2%。收入比上一季度增长18.1%，达到人民币12.921亿元。增长主要来自“QQ空间”、“QQ会员”和“QQ秀”，而“QQ宠物”的下降抵销了部分增长。网络游戏的收入比上一季度增长1.7%，达到人民币15.550亿元，增长主要来自“地下城与勇士”和“穿越火线”两款游戏。

2. 大家调查一下，身边给腾讯贡献收入的主要都是什么用户？12~20岁的街头盲流、被中国脑残教育残害的少男少女虚无一代……拿着家长给的零花钱挥霍…...为什么？这些人好忽悠！

3. 大家再调查一下，身边有正当职业，受过正规教育的人，有几个给腾讯贡献了收入。为什么？这些人有自我判断能力。我从来不上QQ，从来没买过一个Q币，生活幸福，合家欢乐。　

4. 希望大家抛弃成王败寇的观念，拥有300亿美金的市值就牛叉了？钱只不过是铁打的营盘流水的兵，今天赚明天赔，别高兴的太早。腾讯在中国技术史和商业史上留下了什么？将来会留下什么？抄袭，抄袭，抄袭！——十年以后大家再来看腾讯，我相信那时候那些今天的弱智族群也都已长大，而且也会痛记自己的弱智历史，教导下一代不要再弱智，到那一天，我相信QQ死得会比AOL、Yahoo更惨。

5. 腾讯给中国商界的启事是“继续沿着脑白金忽悠弱智族群的道路，忽悠、使劲忽悠用户兜里的钱就是王道！

一个“埋头抄袭、只知忽悠，从不创新，从不奉献“的暴发户，不是中国IT界的榜样，更不是程序员的榜样，而是中国IT界的耻辱。如果大家还把腾讯当作中国IT界的榜样，那将是中国IT界的悲哀！

本文链接

纯转发：谷歌高管对Java、C++的复杂性不满

2010-07-26T14:25:00Z

谷歌高管Rob Pike 在OSCON 开源大会上打开了简化式编程语言新议题今天的商业级编程语言--尤其是C++和Java--太过复杂而不能与今日计算环境充分相容。谷歌资深工程师Rob Pike 在周四于O'Reilly开源大会上的一次谈话中发表了以上论点。

“我觉得这些语言太难用了，太精细，太复杂，太冗长。而且这些缺点似乎在与日俱增，”Pike说，“它们被过度接受，被用得太广了。”Pike详细说明了此类语言的缺点，以此展开描述了他和其它谷歌工程师对所开发的名叫Go的新编程语言所持的期望。

为了证实此类语言的复杂性，Pike展示了一些C++代码示例。其中一例是一个几乎占据了屏幕整行的变量声明。“我们怎么能让这种东西成为在学校里教、在产业里被使用的操控计算机的标准方式？”他问道。这种语言“太官僚了（制度化）。每一步都必须要考虑编译是否可通过，”他说。

尽管Pike承认他自己有点爱开玩笑，他声明说此类问题确实应该被提及。C++出现是因为人们对使用低级语言C绝望，Java出现是为了简化C++。随着时间的推移，新的特性都加在了新出现的二者之上，使它们越来越复杂了。

“成熟（复杂）会带来噪音（不可预知不被期望的错误），”他补充说。Pike还说，此类语言还是在多核处理器和网络被广泛应用等大的事物出现之前被开发出来的，因此它们不能简单地与这些新环境相容。

Pike并不是谷歌唯一一个表达对传统商业级编程语言不满的人。在上个月的USENIX 年度会议上，Gmail工程师Adam de Boor 出语惊动了与会者。他说，公司的Gmail服务完全是由JavaScript写的，总代码全长443,000行，全部手写。

他指出，尽管Java更具有表达性，它也更加繁琐。“在这个节骨点上，对我来说所使用语言的选择问题是一个大问题，”de Boor说。JavaScript是为避免C++和Java不断增长的复杂性，而在过去十年里被开发出来的一批语言中的一支。其它支还包括Ruby和Python。但是尽管有了一个简化了的语法，这类语言也同样有它的弱点，他论证道。

这类新语言要慢一些，伸缩性较差，还隐藏了更多的错误，Pike详尽地描述道。这类语言多为解释型而非编译型，它意味着用这类语言写的程序在运行前是没被编译过的，因此运行的缓慢得多。它们也倾向于使用动态数据类型，即程序员无需定义他们变量所属的数据类型。“动态数据类型并不见得好。本来你可以在编译时找出的错误的，它（动态数据类型）让你只能在运行时找出错误，”他说。

借着这些观点，Pike接下来描述了作为融合两类语言集各自优点的一个大胆尝试--Go语言。“Go是把静态数据类型语言的安全与效率和动态数据类型解释型语言的方便与轻松结合起来的一个尝试，”他说，“它到底能做多少，还得你亲自去尝试了才知道。”

与会人员Larry Augustin, 客户关系管理软件提供商SugarCRM的CEO对Pike所指出的C++和Java变得太复杂了的观点表示赞同，尽管他也说这是在一切为应对广泛应用需求而发展的语言身上所发生着（了）的。

“这些语言在复杂度上增长的原因是，它们用得越多，我们就会发现越多的错误和二义性，然后为消除这些错误和二义性而做的工作又创造出了一些更复杂的东西出来，”具有软件工程和程序语言设计背景的Augustin这么说。

“我很欣赏你们的目标，”他谈及Pike等人的努力时这么说。“问题是他能否达成那一目标，抑或是在被越来越多人用之后，它也会变得很复杂，”Augustin说。

英文原文：http://infoworld.com/d/developer-worl ... ted-java-c-complexity-375

P.S. 最近孩子住院，抱歉没有时间照顾blog，但是绝没有隐居山林之意，我近期会将系列文章持续写下去，谢谢大家－特别感谢那些坚持独立思考、永存怀疑精神的程序员！

本文链接

关于近期C#大论战的回应

2010-07-09T08:53:00Z

自从在cnblogs和csdn写了几篇批评C#/.NET的博文后，便受到了多方.NET粉丝的轮番群殴：http://www.cnblogs.com/topic/53/。这段时间正好出差，没有及时回复，便被某些朋友视作理屈词穷。其实，我在第一篇博文中就说过，我既然列出这些论点，一定有支持这些论点的实践证据和技术原因——也许有些观点错误，但是我总有我的道理。说出来，和大家分享讨论而已——没有及时回帖，只是工作原因，绝不会理屈词穷，请大家放心，我还会继续战斗下去，呵呵:)

我仔细看了目前为止参与“群殴”的博文，说实话，大部分都是没有技术含量、错误百出的。比如如下观点：《说透事件和接口，两者怎能互相替代》：http://www.cnblogs.com/waitrabbit/archive/2010/07/02/1769948.html　博文中直接说“事件是特殊的委托”？　就这水平，还能“说透？”。先搞清楚什么叫“委托”，什么叫“接口”，什么叫“事件”吧！　再比如：《完全水文系列之0xFA：函数背后的臃肿设计哲学》：http://www.cnblogs.com/winter-cn/archive/2010/07/05/1771098.html果然是水的厉害，自己都承认水了。我就不回应了。

不过，可喜的是，在众多水贴之中，确实还出来了几篇高质量的帖子，这是让我非常高兴的，也算是对我写系列博文的一个回报吧。目前看到的主要有以下几个帖子我列举如下，并且加上我的回应（如果有朋友认为自己的帖子质量很高，技术水平很深，我遗漏掉了，请在下面回帖，我会认真拜读并回应），与大家一起讨论、共勉：

1. 李建忠《Metadata是.NET平台的核心灵魂》：http://techvery.com/jzli/2010/07/07/metadata是-net平台的核心灵魂/

这篇博文是目前我看到技术分析最深入的一篇博文，让我很受益。李建忠是我尊敬的一位.NET技术专家，我承认学习.NET就是从拜读李建忠翻译的《.NET框架程序设计》（Jeffrey Richter著，后改名为CLR via C#）一书开始，我也参加过李先生公司去年举办的.NET技术大会，才有前文提到的和Jeffrey Richter大牛的对话。

李建忠在这篇博文中批判了我之前博文中的一个论据“.NET平台中metadata的目的是为了支持反射”。我必须坦白地承认，我之前确实一直认为“metadata就是为了支持反射才创建的。”　经过李建忠博文的分析，我承认在这个问题上认识不到位，观点偏颇。并且非常同意李建忠博文的观点“.NET使用metadata的主要目的是实现组件的高度复用性”。

李建忠博文中还有很多很有价值的技术分析，比如COM的缺点，.NET为什么使用metadata？metadata都在.NET中有哪些具体的应用？特别是“基于逻辑语义的组件复用”和“基于物理实现细节的组件复用”的对比，受益匪浅。

拜读过这篇文章之后，我也承认“基于逻辑语义的组件复用”对于软件开发平台非常重要，不过却有一点要和李建忠商榷，难道“性能就不重要了吗？”，“.NET为了基于逻辑语义的组件复用，就可以大幅度地牺牲软件的性能吗？”，非常希望听到李建忠和网友的继续分析。

2. mikelij《关于.net反射和metadata加载--致Jeffray Zhao等几位和firelong》：http://www.cnblogs.com/mikelij/archive/2010/07/04/1770897.html

mikelij这篇博文涉及到两个观点：

a. 我在前面分析反射时的观点：程序（EXE/DLL）最后都是要加载到内存中运行的，不是光放在硬盘上的——这也是为什么.NET程序占用内存都超多。

b. Jeffray Zhao在前文中反驳我的观点是 "不JIT的话，是不会把整个dll加载到内存中的，而是用多少加载多少，这点已经讨论了很多遍了"

mikelij这篇博文非常细致的分析和数据说理，以及其后面的网友跟帖讨论已经清楚表明了，我在这个问题上的观点是正确的。不过后面有很多跟帖一直在说“任务管理器里面的内存占用很小，所以说明老赵的观点是正确的，即调用哪个方法，就加载哪个方法和它的元数据。用不到的方法，不加载”。

这个里面触及到了一个较深入的话题，即Windows操作系统的内存加载规则和Windows任务管理器的数字含义。　我对这个问题的回应如下：

Windows任务管理器显示的内存大小指的是“工作集working set所使用的内存大小”，也就是当前运行期加载到CPU缓存里面的内存大小。并不是程序运行期间所有加载到内存中的数据。这些数据有可能停留在主存，或者虚拟内存即硬盘上——这就是性能成本，因为这很快会因为调用而遇到page fault, cache missing的问题。只是因为它们当前不被调用，所以没有放在working set缓存中，但是并不表明它们不被加载到主存或者虚拟内存中。

而程序在运行期间，EXE/DLL整个程序集是整体被加载，而不是部分加载——不会因为你只用一个程序集中的方法A，就只加载方法A。而是会将程序集中其他类、方法、元数据都加载进去：mikelij这篇博文充分证明了这一点。

JIT编译是按照方法为单位——即用哪个方法，编译哪个方法。但是加载是按照程序集为单位，不是以方法为单位——老赵在这个问题上的认识让人失望。

谢谢mikelij这篇数据翔实的博文！

3. 老赵《我支持托管运行时（虚拟机）：http://blog.zhaojie.me/2010/07/why-i-support-managed-runtime-virtual-machine-based-program.html

实话实话老赵对.NET的很多分析还是有益的，至少让我可以深入再思考一些问题，虽然老赵经常犯一些幼稚的错误（比如前面的将程序集的加载问题，混淆成了JIT问题）。　这篇文章中，老赵说了好几个虚拟机的优点，我整体比较同意，比如实现跨语言，“跨执行环境”等。

但是说虚拟机完全可以实现比native代码更高的性能，则有点过于他信.NET了。特别是举出了一个虚函数的内联优化的天方夜谭的神话，一个虚函数即便循环调用，你也绝对无法去预先判断下一次的调用地址——如果可以判断，这个判断的成本，要远远高于内联所节省的性能成本（而且是每一次都要判断！）。老赵这个真的实现了吗？能不能给出参考地址？

虚拟机可以实现的优化，native代码都可以，而且优化力度要大得多。但是很多native可以做的优化，虚拟机就不行。虚拟机，顾名思义要经过一层间接，我无论如何都想象不出来，间接层可以提升性能？希望老赵能够深入分析一下原理或者给出案例。

本文链接

C#会重蹈覆辙吗？系列之3：事件背后的臃肿设计哲学

2010-07-01T15:07:00Z

1. 事件没有通用性

绝大多数对象没有事件的设计需求，不会实现事件。

2. 事件没有抽象性

事件并非对象的基本元素，并不反映对象的关键抽象。字段反映对象状态，方法反映对象行为，事件反映什么？一个观察－通知的关系结构吗？

3. C#事件的实现性能比较低下.

a.C#事件的背后是一个委托链表（单链表），单链表的遍历调用性能远低于数组链表（List<T>）

b.C#事件默认实现会产生一个委托字段实例，支持不用的委托字段实例是一个性能负担（参见WPF/SL里面的路由事件的改造设计）

4. 事件没有必要性——这一条是C#事件最大的问题

事件只是观察者设计模式的变体。其完全可以用接口来实现。

将所谓常用的设计模式变成语言构造的一部分，是C#设计思想里面又一个的严重错误（第一个严重错误是为了所谓的功能，而不管不问性能成本，在前文《C#会重蹈覆辙吗？系列之2：反射及元数据的性能问题》中对此有详述）。

C#中类似的例子还有：使用foreach和yield支持迭代器模式，使用using支持Dispose设计模式。

如果可以在C#语言中内置Observer模式，内置Iterator模式, 内置Dispose模式，那么要不要也把Adapter模式变成C#语言的一部分？要不要把Proxy模式也变成C#语言的一部分？要不要把Bridge模式也变成C#语言的一部分？.....几百种模式是否都要变成C#语言的一部分？？？...

另外，在语言中内置设计模式，会使得该模式失去实现上的灵活性、或者损伤性能（比如C#事件就限定了观察者模式必须使用委托来完成事件调用，使用委托链表来表达观察者的对象集合，这种限制使得设计模式失去了其实现上的灵活性）

使用程序库来支持设计模式是编程语言的正道，将模式集成为语言的一部分来耍cool，最后的结果是这个语言越来越臃肿，越来越庞大。希望C#设计师们在这条道路上止步。

今天来谈谈C#语言中事件的设计问题——这是除了性能问题之外，C#语言设计哲学中另外一个严重的问题——不必要的臃肿。C#事件总共存在以下４类问题：

1. C#事件没有抽象性
事件并非对象的基本元素，并不反映对象的关键抽象。字段反映对象状态，方法反映对象行为，事件反映什么？一个观察－通知的关系结构吗？

2. C#事件没有通用性
绝大多数对象没有事件的设计需求，不会实现事件。

3. C#事件的实现性能比较低下
a.C#事件的背后是一个委托链表（单链表），单链表的遍历调用性能远低于数组链表（List<T>）

b.C#事件默认实现会产生一个委托字段实例，支持不用的委托字段实例是一个性能负担（参见WPF/SL里面的路由事件的改造设计）

4. C#事件没有必要性——这一条是C#事件最大的问题，也是本文的重点

事件只是观察者设计模式的变体。其完全可以用接口来实现。

C#中类似的例子还有：使用foreach和yield支持迭代器模式，使用using支持Dispose设计模式——我就在这里一并批评了，不再另外撰文了。

如果可以在C#语言中内置Observer模式，内置Iterator模式, 内置Dispose模式，那么要不要把Adapter模式也变成C#语言的一部分？要不要把Proxy模式也变成C#语言的一部分？Bridge呢？Composite呢？Strategy呢？.....几百种模式是否都要变成C#语言的一部分？？？...

本文链接

感谢比尔盖茨定律——.NET十周年贺词！

2010-06-26T18:13:00Z

值此.NET十周年之际，作为伟大.NET社区的一员，我于近日收到许多.NET社区先醒分子，以及Java、C/C++、PHP等友邦团体发来的贺信贺电，赞扬我“只说.NET差，不说.NET好”的批判怀疑和自我牺牲精神，感谢我“勇于献身，说出了大家在心中憋闷已久的共同心声”，同时勉励我“继续说真话，继续做仰望星空的程序员，发扬特别能吃苦，特别能战斗的革命主义精神……” 为了不负大家的厚望，firelong决定值此.NET十周年庆典佳节，咗合短文一篇，聊表纪念。

做IT的朋友都知道摩尔定律吧。其由英特尔创始人之一戈登·摩尔发现，摩尔定律定义如下: 微处理器芯片上，每隔18个月，集成电路数目翻一番，性能提高一倍，价格降一半。这一定律揭示了硬件工业前进的规律。被IT界人士视为行业的发动机（虽然现在在单核上有点接近极限了）。

接触摩尔定律是最早在大学课堂上，当时将信将疑——青春期嘛，怀疑一切:) 但是几年下来，对摩尔定律的威力还是有亲身体验的。比如我96年的时候玩的第一台电脑386，CPU 33MHZ，内存:8M，运行Windows 3.1，到后来的486、奔腾……一直到今天的4G内存，4核2.4GHZ。CPU涨了大概100多倍，内存涨了大约500多倍。与摩尔定律大致相符。

但是这种相符的感受也仅限于购买电脑时候的配置单。当真正用起电脑来，却从来没有感受到摩尔定律“18个月性能提高一倍”的畅快。—直到在CPU涨了100倍，内存涨了500倍的今天，用Windows 7和当年用Windows 3.1、Windows 95的速度感觉没啥差别，甚至感觉更慢。我甚至一度为此用一个螺丝刀撬开过一个CPU，想看看是不是Intel等公司在骗人——不过很遗憾，CPU转速太快，肉眼能力有限，转圈数实在数不过来。

但是当我从事软件开发行业，特别是.NET平台上的软件开发后，我才发现了秘密所在。我在本文中暂且将其定义为“比尔盖茨定律”——虽然未经比尔盖茨大叔同意，但毕竟是他设计的整个.NET战略嘛！我不敢掠人之美。比尔盖茨定律的定义如下：.NET平台上，每隔18个月，软件占用内存大小翻一番，性能降一半，价格升一倍。

原来除了硬件行业的“摩尔定律的加速度”外，软件行业还存在一个“比尔盖茨定律的减速度”，而且：摩尔定律×比尔盖茨定律＝常数！

这就是我们这么10几年来，硬件速度飞涨，而使用电脑时却没感到速度上升、甚至不升反降的秘密所在啊！

10年来，比尔盖茨定律一直是我们伟大.NET平台开发人员的最高指导思想——摩尔大爷，你很牛叉是吗？上我开发的.NET软件，绝对把你抹平！　作为在中国实践“比尔盖茨定律”的广大.NET程序员，我们要感谢盖茨大叔！另外，一定要记得先感谢国家:)

本文链接

C#会重蹈覆辙吗？系列之2：反射及元数据的性能问题

2010-06-24T09:42:00Z

理清几个基本点

在开始谈论性能问题之前，有必要首先理清几个基本点。我们谈C#，就是在谈.NET Framework（或者更准确一点是CLR，因为.NET Framework除了CLR还包括BCL）；谈.NET Framework（CLR），也就是在谈C#。因为支撑C#语法之后的就是整个CLR的机制。因此，我说C#性能不好，和说CLR性能不好，说的是一个事情（就像说Java性能不好，就是说JVM性能不好一样）。我不希望在我下面说C#某个地方性能不好的时候，再有论者立即指出来“那不是C#的问题，那是CLR的问题，或者.NET Framework的问题”——如果对C#和.NET还停留在这个认识上，请先去读读Jeffrey Richter的《CLR via C#》一书，再来看我下面的文章。

另外，我说C#性能有问题，仅针对C#而言，与我对其他语言的态度无关。我既不是Java的支持者（因为Java的性能比C#还慢），也不是C++的支持者（C++太过臃肿复杂），也不是C的支持者（没有基本的面向对象抽象和垃圾回收）。我既不喜欢任何语言，也不讨厌任何语言。编程语言在我只是一个工具——我只是希望这个工具是把锋利的牛刀，而不是把功能齐全的瑞士小刀。

最后我不是毫无选择地反对“新功能”，我反对的是“添加的功能、没有重大抽象意义，却带来性能损失”，如果有“提高性能的新功能”——比如并发编程，或者“对管理软件复杂度”有重大意义，同时性能损失很小很小——比如面向对象，那我举双手赞成。”

在理清了前面几个基本点之后，下面开始来针对我前文说过的一些问题一一“讲原理”。这篇文章中，我首先来剖析反射的性能问题。

反射的两大类性能问题

【一】反射绑定与调用——使用反射带来的性能问题

反射的绑定与调用性能差，我想大概做过.NET开发的人都不会怀疑这一点。但是我还是希望那些严肃的程序员认真看看微软CLR程序经理Joel Pobar在MSDN上的这篇文章：Dodge Common Performance Pitfalls to Craft Speedy Applications　http://msdn.microsoft.com/en-us/magazine/cc163759.aspx，清楚理解反射绑定与调用的效率到底为什么那么差？有多差？差在哪里？

限于篇幅关系，我简单在这里总结一下，反射绑定与调用的性能问题（具体原理，大家参照MSDN这篇文章）：

首先要经过一个绑定过程，非常耗时（用字符串名称和metadata里面的字符串进行比对，字符串查找的算法大家都知道是很慢的操作）
然后要进行参数个数、类型等的校验；如果不匹配还要搜索可能的类型转换
进行CAS代码访问安全的验证，看允不允许调用。
以上几个工作，如果不用反射应该是由C#编译器负责在编译时检查的。但是现在如果用反射，全都放到了运行时检查。
这其中会产生一大堆的临时对象（比如MemberInfo Cache），给垃圾收集器造成巨大负担
纵然有一些对反射绑定和调用的cache优化策略，Joel Pobar在这篇文章中给的最大的建议还是：能不用反射，则不用反射，因为性能成本太高。
结论：反射调用的性能成本很高（参见msdn文章中中图2 Relative Performance of Invocation Mechanism）。

我想这些性能问题，大家都会认可。但有些朋友会说“我.NET程序中用反射的很少啊？”，首先且不论你用的少不少，但是微软开发的很多Application Framework对反射的使用现在越来越多，比如大量使用反射“绑定与调用”的例子（注意是大量，不是一点点！）：

WPF和Silverlight中的XAML序列化－反序列化，依赖属性，数据绑定
ASP.NET MVC中路由、控制器，视图等的匹配查找（反射绑定）和调用（反射调用）
WCF分布式通信中大量的实例激活，方法调用，序列化与反序列化
WF中大量的工作流流程激活、控制、调用
………..上面几乎把.NET平台的主要应用框架都包括了，不用再举更多例子了吧？谁能脱离这些应用框架去写程序？

所以说，你用反射用的少，并不代表你最后做出的软件用反射的少（你的软件的代码不可能全都是自己写的，很多都是依附于微软的Application Framework，只要这些Application Framework很重地使用了反射，那么你的软件也就很重的使用了反射）

但有朋友会立即指出“我不用WPF/SL，不用WCF、不用WF、不用ASP.NET MVC，类库都是自己写，代码全都是自己写，保证反射用的很少，甚至确保压根没有使用反射，这些性能负担不久没有了吗？”这个问题很好！　也是前面谈到.NET各种功能带来的性能问题的时候，很多朋友最喜欢的辩词——不用它不就是了嘛！

首先如果有这样的C#程序员，我定佩服你如滔滔江水…….但是，我这里要告诉大家的事实是，“即便你程序中确实所有的代码都不使用反射，由于C#/.NET内置地支持反射，那么你也要为此付出性能代价，而且是很高的性能代价”。这是本文的重点，甚至是我后续很多论战文章的重点——很多C#/.NET机制，不管你用不用它，只要内置支持这种机制，就不可避免要付出性能代价（当然如果你要用它，还有更多性能代价）。

好，下面让我们来谈谈为什么，即便不用反射也要付出很高的性能代价？（这也是MSDN那篇文章所刻意回避的话题）。

【二】反射背后需要的支撑机制：元数据的性能问题——不使用反射的性能问题

要谈这个问题，首先大家应该清楚C#/.NET中反射的功能是由metadata来支持的，即便你所有的代码中、你用的所有Application Framework的代码中都没有使用一点反射的API，C#编译器还是会在最后生成的EXE或者DLL中生成所有的metadata。（如果这个不清楚，请先读Jeffrey Richter的《CLR via C#》一书）。而 Metadata就是C#/.NET性能的罪魁祸首！要理解这一点，大家先来做两个简单的针对metadata的分析。

１. 用ILDASM工具将C:\Windows\Microsoft.NET\Framework\v4.0.30128　下面的MSCorlib.dll（.NET核心类库程序集，其他版本也可以，不必非要4.0）打开。点击：View->Statistics，看一下其中的元数据大小：

CLR header size : 72 ( 0.00%)

CLR meta-data size : 2083724 (40.09%)

CLR additional info : 931312 　 (17.92%)

CLR method headers : 136967 ( 2.64%)

Managed code : 1212346 (23.32%)

Data : 753152 (14.49%)

注意：这四个部分，其要么是metadata，要么是metadata的辅助信息，所以我在后面文章中都算作元数据部分：

整个MSCorlib.dll大小为4.95M。

Metadata总共占用大约3.01M，占总大小大约60.6%。

真正传统的Code+Data总共占用大约1.87M，占总大小约37.8%。

MSCorlib.dll总共大小4.95M，为了支持反射，需要添加的元数据竟然有3.01M，占到60%的大小！！！我想大家已经看出问题来了。有些朋友可能会说，这是特例吧？别的DLL呢？

２. 我们再来随便找一个DLL，比如WPF的DLL：C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.0\PresentationFramework.dll，同样适用ILDASM打开，点击：View->Statistics看一下其中的元数据大小：

整个PresentationFramework.dll大小为5.03M。Metadata总共占用大约55.15%！

大家可以随便拿一个自己项目中.NET的DLL或者EXE来分析，看看Metadata的大小占用多少？　基本都在50%以上，甚至有的高达70%！　

这意味着什么？即使你不用任何反射的代码，C#/.NET为了让它支持反射，还要给你最后生成的DLL/EXE强加50%以上的metadata（这是强制的，即便你不用反射，C#/.NET也没有提供任何编译选项将这些metadata去掉）。这就是.NET Framework　Redistributable本身要40M左右的原因！

我想这个铁的事实是“老赵们”无论如何都不能否认的。但是“老赵们”的典型言论马上又来了：

（１）不就是程序有点大吗？现在大硬盘很便宜，运行起来还是很快的

（２）就是.NET Framwork有点大，客户安装起来不方便

（３）大只是空间效率，不影响程序的时间效率

这些调调显然都是没有真正搞过“性能优化”的“老赵们”的浅见。空间效率并非对时间效率没有影响，而是有致命影响。一个100M的应用程序，运行起来肯定要比一个40M的程序慢许多。理由如下：

（１）程序（EXE/DLL）最后都是要加载到内存中运行的，不是光放在硬盘上的——这也是为什么.NET程序占用内存都超多

（２）占用内存多的程序，运行起来必然慢。因为内存大的程序必然会出现较多的page fault（即换页错误），cache missing（即缓存失效）（简单来说，要尽可能在CPU缓存中操作working set，CPU缓存装不下，就要跑到主存里面找；主存装不下就要跑到虚拟内存－也就是硬盘里面找，那样软件运行的性能代价非常高）. Page fault和cache missing已经成为现代软件性能的一大公害。很多程序慢下来，如果不是蹩脚的算法，Page fault和cache missing往往都是罪魁祸首！关于这方面的理论，很多牛人都专门讲过，国外也有比较牛叉的咨询公司专门做这方面的优化，大家如果想深度理解这方面，可以参照：

a. CACHE MEMORY：IMPLEMENTATION ANDDESIGN TECHNIQUES

http://www.faculty.iu-bremen.de/birk/lectures/PC101-2003/07cache/cache%20memory.htm　

b. Improving Managed Code Performance－Working SetConsiderations

http://msdn.microsoft.com/en-us/library/ff647790.aspx#scalenetchapt05_topic33

c.以及微软的.NET性能经理Rico Mariani在这里的文章：

My mom doesn't care about space，http://blogs.msdn.com/b/ricom/archive/2004/03/15/89934.aspx

所以，总结下来就是：

（１）Metadata非常占用空间，一般占到整个EXE/DLL总大小的50%~70%

（２）高昂的空间成本会由于Page fault和cache missing等因素转嫁为高昂的时间成本

（３）即便在代码中不写一行反射调用代码，所有的metadata仍然会生成，我们仍然要为此付出高昂的空间代价和时间代价。

比如，我们公司开发的一个大型医疗软件，之前的版本使用C++开发，整个生成代码体积为40M左右，但是转移到.NET平台上（被微软的.NET平台战略忽悠过来）后发现代码体积为130M左右（功能差不多的前提下，第一版主要是移植，新增功能的代码量占不到5%），我们反反复复怎么优化都优化不到原来的40M左右，最后发现都是反射惹的祸！——我相信我在前文举出的很多世界著名、或者中国著名的软件最终没有选择.NET，都有过这样一个评测过程。

其他的例子大家可以自己找，比如就拿mspaint.exe 与paint.net（到这里下载：http://www.softpedia.com/progDownload/Paint-NET-Download-19322.html）比较比较，功能差不多相同。运行一下看看，它们各占多少内存：前者5.7M，后者占用17.7M！3倍多！

软件size大，没关系，你要大在地方，比如因为功能原因，code多一些导致size大我接受。但是你50%-70%的size都去装metadata了，而我又不怎么用metadata（反射），你还要这么大放在那里，极大地损害软件性能。

这还是一个小小paint玩具软件！你让QQ、photoshop，office等软件用C#/.NET开发试试？除非是“老赵们”自己开公司玩。

反射性能问题总结

好了，我相信问题已经分析清楚了，总结一下到目前为止，这篇文章的重点：

１. 反射的绑定和调用成本很高

　—— C#反射绑定与调用过程中元数据字符串比对，参数校验，安全校验，大量临时对象，会让使用C#反射时的软件性能很差，尽量避免使用

２. 你不使用某些性能低的功能，不代表你依附的Application Framework不使用这些功能

　—— 目前.NET平台中WPF/SL, WCF,WF, ASP.NET MVC等几大核心的框架都很重地使用了反射

３. 有些功能即便程序中不使用，为了支持这种机制，也要付出很高的代价

　—— 哪怕所有的代码都是你写（不用Application Framework），而且不用一点反射的功能，C#编译器还是给你的软件中加了很多支持反射的metadata，占用很高昂的空间成本（大约是整个软件size的50%）

４. 只要有较大的空间成本，那么时间成本也一定很高

—— 反射背后的metadata占用的高昂的空间成本，由于内存加载、working set、cache missing 等各种问题，直接导致的时间成本很大，严重影响软件的运行性能。

上面的分析方法、依据、包括数据都是我和公司美国、德国同事，在开发C#/.NET产品时（大型医疗软件），遇到的非常实际的问题（客户接受不了C#/.NET写的软件速度），用符合工程的系统、全面的分析方法，研究各领域专家的分析意见（包括很多微软技术专家），对C#/.NET进行的性能研究（不是写个CodeTimer玩具比较比较两段代码就叫性能分析），我们尝试了很多优化策略——最后的结论就是绕不开C#/.NET底层设计带来的根深蒂固的性能问题！反射就是一个性能公害！

好，相信看到这里，绝大多数朋友已经深入理解了“反射所带来的严重的性能问题”。但是有很多朋友可能还会有疑问，咦？怎么有些人写C#性能也不错，而且写得头头是道，似乎很有道理啊。到底谁说的对啊？

这样的疑问很正常，这些论调就是我前文说的“只见树木，不见森林”。为了理清网友的疑问，我在下面的小节中针对这些“一叶障目”的观点进行一一戳穿，以便于大家今后明辨是非。

几种典型的错误的性能论调或方法

１. 函数计时论

要比较性能吗？那好我们写一段函数，用一个时间计数器，在函数执行开始处记录下时间，在函数执行结束前记录下时间，最后一减得到的时间差，同样的功能，哪个语言（或者哪种方式）用的时间少，哪个语言（或者哪个方式）用的时间多，性能差别，一目了然。多客观啊！！！

比如，老赵曾经在这篇博文中：一个简单的性能计数器：CodeTimer　http://www.cnblogs.com/jeffreyzhao/archive/2009/03/10/codetimer.html　抄袭.NET技术大会上Jeffrey Richter老人家show的性能计数器。

然后下面这两篇文章都是用这种“函数计时论”：

《C# vs C++ 全局照明渲染性能比试》:　http://www.cnblogs.com/miloyip/archive/2010/06/23/cpp_vs_cs_GI.html

《回firelong之C#慢》　http://www.cnblogs.com/sumtec/archive/2010/06/22/1762564.html

问题是这种做法真的全面、客观的反映了编程语言的性能了吗？？？用这种办法你可以说某一段C#代码性能还凑合（比如《C# vs C++ 全局照明渲染性能比试》一文中的实验结果，比C/C++差也就20~30%嘛，差的不多嘛！），但是问题是，这就是它们性能差别的全部真相吗？

函数记时论，测量的只是某一个微观代码段的性能。不是一个软件的总体性能。比如“函数记时论”就常常忽略掉我们前面metadata所带来的高额的“空间成本”和“时间成本”。正规公司，只要是care性能的，对于性能评测都有一个系统的、全面的、完整的过程（比如在我们公司称作Performance Process，和单元测试、重构、等都作为一个严肃的软件开发过程中的一个环节而存在），会借助一些系统性的工具：比如Compuware的Application Performance Management Solutions：参见这里：http://www.compuware.com/solutions/application-performance-management.asp来做一些系统性的评测报告。不是拿个CodeTimer这样的玩具输出几个时间值，就拍脑袋下结论的。

函数计时论经常在各种技术社区中，吵架时展示的tricky demo中用于比较性能，但是放到一个正规公司的严肃项目里面，绝对不会使用这种方法来评估一个编程语言，平台，或者软件的性能。

我希望 “老赵们”以后不要再拿CodeTimer这种玩具说事，要真全面比较性能，用Compuware的Application Performance Management Solutions一整套工具和过程来比较整个软件的性能，而不是某一段微观代码的性能。

２. 性能选择论

某个功能影响性能，你不用不就没影响了吗？又没有人逼你用！

前面已经证明，C#/.NET的反射功能，你哪怕一点也不用，也有很大的性能成本（即：代码中完全不用反射，为了支持反射的metadata带来的空间成本和时间成本也非常高昂）。所以希望以后“老赵们”不要再说这样的话。

３. 损失忽视论

这个功能带来的性能损失是很小的，可以忽略不计。

性能是一个软件最核心的使用指标——如果一个软件性能不行，就是差软件！没有哪些个性能损失是可以忽略不计的。因为在程序代码中，任何一个性能损失点，都有可能因为各种因素被放大（比如长循环，大规模并发用户等）。

“老赵们”喜欢写“性能不咋地的高级企业应用”，然后忽悠客户加硬件。但是请不要忽悠整个.NET社区的程序员以为天下的软件都是“很高级的企业应用”。

４. 性能垫背论

“Java的这个feature性能比C#的差，所以C#这个feature性能好”——C#的某些feature（比如反射）性能比Java好，但并不能说明这个feature本身没有性能问题（这只能说明Java在这个上面性能太差，说明不了C#性能好）。

请“老赵们”以后不要天天在.NET社区里说“C#这个比Java好，那个比Java cool”，这就像天天告诉自己的孩子，你比你们班最后一名的那个孩子好多了，你说孩子还能学好吗？？？你怎么总拿C#跟差的比，不跟好的比呢？

最后结语

好，文章写完了，我希望.NET技术社区的“老赵们”围绕“反射的性能话题”来辩驳，不要扯别的话题来放烟雾弹（C#/.NET中别的技术话题，我会在下面的文章中一篇一篇来讨论，请大家耐心等待给我一点时间）。谢谢！

正要贴本文的时候，看到《关于C#开发山寨操作系统,程序语言,浏览器,IDE,Office,Photoshop等大型程序的可行性歪论及意义》http://www.cnblogs.com/DSharp/archive/2010/06/24/1764210.html　这篇文章。我的回答非常明确：没有任何可行性，且不论商业可行性、其他技术问题，光反射一项带来的两大性能负担就把路堵死了——这也是我前文说的那么多软件为什么不采用C#开发的一个关键原因——你搞一个100M的程序，中间有50M都是metadata，你还让人程序活下去吗？（记住，50M不仅仅是空间成本，带来的时间成本照样很大！）

P.S. 本文中的“老赵们”指的是那些天天拿着C#语言新特性耍酷表演、而不研究真实技术问题的“所谓的技术精英们”，并不特指老赵一个人，或者老赵的每一个阶段（老赵有一段时间还算在研究真问题）。请不要对号入座，谢谢！

本文链接

多研究些问题，少谈些“主义”

2010-06-23T05:31:00Z

自从前面在cnblogs上写了帖文指出C#发展历程中的问题之后，就好象捅了马蜂窝一样。围绕老赵们和老赵粉丝们的逻辑就是：“我在用C#，只许捡C#好听的给我说。别说任何C#的不是；说C#的不是，就是跟我过意不去，就是触犯众怒“。我99年就开始在技术社区混，没想到10年过去了，技术社区还是这种风气和逻辑？我不知道这是cnblogs社区的习性？还是整个中国技术社区的习性？

因此我刚刚在csdn上也开通了博客：http://blog.csdn.net/firelong2010。欢迎csdn的网友们观战评论。打算同时在cnblogs、csdn开博的原因有三：

１.　看看其他技术社区的人的技术“水平”和“习性”；　

２.　避免我最后在cnblogs真的触犯众怒，被大量不明真相的群众踩死，最后以身殉博；

３.　有利于其他技术社区的人参与进来（cnblogs的评论必须是cnblogs的注册用户，这点把很多人挡在门外）。

我也欢迎其他技术社区如果感兴趣帮我开博，我会非常乐意接受（可以在本贴后面留言）。我将在观看南非世界杯的日子里抽出宝贵的时间，同时在几个技术社区发博，回应各个技术社区的评论。

再次声明：这次发起的旷日持久的论战（是的，至少持续一个月，因为太多问题不是只言片语能讲清楚的），不是为了博眼球（我不为出名，因此匿名），争上镜（我不给谁做广告），更不是为了挑起口水战。　而是实实在在感觉到C#这10年来发展中单纯追求“新酷功能”的整个思路严重错误——实际上2005的时候我还对C#的发展非常有信心，但是现在彻底失望了。特别是在国内技术社区这些“老赵们”的鼓噪下，很多程序员走上了一条非常错误的道路。

我希望在cnblogs、csdn以及国内更多技术社区发起的这场论战，能够带来以下两大价值：

１.　反思C#编程语言发展中的问题，尝试找到什么更好的办法。

２.　引导程序员社区（特别是C#程序员）建立正确的编程素养价值观。

我看到的是问题，而很多朋友在谈的都是主义（如果不是脏话的话）。

比如这几天cnblogs上充斥的都是这类：

讨论？讨论你妹啊。

http://blog.zhaojie.me/2010/06/no-room-for-discussion.html

讨贼檄文

http://www.cnblogs.com/wenwuxianren/archive/2010/06/23/1763389.html

C#呓语

http://www.cnblogs.com/Ivony/archive/2010/06/22/1762514.html

对于这类文章，我以後一概不理会。

讨论？讨论你妹啊。　http://blog.zhaojie.me/2010/06/no-room-for-discussion.html
讨贼檄文 http://www.cnblogs.com/wenwuxianren/archive/2010/06/23/1763389.html
C#呓语 http://www.cnblogs.com/Ivony/archive/2010/06/22/1762514.html
........　更多的就不一一在这里贴出了。

上来就是扣屎盆子打架的，对于这类文章，我以後一概不理会。而真正谈论问题的帖子少之又少，比如：

C# vs C++ 全局照明渲染性能比试 : http://www.cnblogs.com/miloyip/archive/2010/06/23/cpp_vs_cs_GI.html

回firelong之C#慢　http://www.cnblogs.com/sumtec/archive/2010/06/22/1762564.html

我非常欢迎这类文章，不过很不幸，目前这两篇文章都是“只见树木，不见森林”，从而得出错误的结论。对这类错误的纠正是义不容辞的责任。

我会很快在后面的文章里详细解释为什么这两篇文章所用的方法和得出的结论是“只见树木，不见森林”，详细解释“C#/.NET性能差的核心技术原理”，并告诉大家什么是正规公司判断软件性能的正规方法。

谢谢等待。

本文链接

C#会重蹈覆辙吗？系列之1：论C#性能不能承受之慢

2010-06-21T19:33:00Z

针对firelong在前贴《C与C++社区混战，C#会重蹈覆辙吗？》http://www.cnblogs.com/firelong/archive/2010/06/20/1761357.html 中发布的博文，评论者众。似乎触动了.NET社区每个人的奶酪——我那么喜欢C#的那些特性，firelong凭什么指责它们，大呼小叫的屎盆子便扣将过来。

Firelong既然写了帖子就有充分的技术原理依据，和工程实战依据。没有动谁奶酪的意思，只是善意提醒。也不会怕扣屎盆子。更不是为了博眼球，骗点击量——firelong儿子都四岁了，早过了穿奇装衣服、批黄头发吸引人注意的年龄了。

Firelong只想与大家好好讨论问题，事实上firelong是个C#多年的研究派和实战派，对C#的感情比大多数人更强。只是firelong已经嗅到了C#发展道路上的一股歪风邪气（新功能！新功能！再来一个新功能！cool，cool，很cool！）。殊不知，编程语言是来解决软件问题的，不是一个功能集合的show场——可惜国内绝大多数.NET程序员（特别是老赵们）对语言还停留在这个认识水平上。这正是国内.NET技术社区总体相对其他技术社区（比如C++社区，比如Java社区）显得比较弱智的原因。而所谓的社区精英（老赵们）又不好好研究软件问题，而是天天告诉大家这个新功能cool，那个新功能niu的来骗取眼球。你看看人家C++社区和Java社区，早跳出了把玩语言新特性的阶段了，而是注重研究真问题。firelong看不下去国内.NET技术社区继续这样沉沦下去。这正是firelong决定写博呐喊的原因。

好了，言归正传，firelong讨论技术会严格遵循“摆事实，讲原理”的guidline，不会意气用事。

Firelong首先来谈性能问题，这是C#语言在不断塞入新功能后所带来的最严重的问题。其他问题firelong也会在后续的帖子中一一道来。由于性能问题比较复杂，firelong首先在这篇帖子中先“摆事实”，然后在后续的帖子中“讲原理”，firelong相信这样会把问题说透彻。

下面开始摆事实。也就是C#性能不好的事实。而且一定要是较为全面的事实，而不是拿一两款软件来说事（我也希望其他论者不要拿一两款软件说事）。我们从目前世界或者中国存在的几大类常用软件（不常用的软件不在firelong性能评价之列，因为不具代表性）开始来谈谈事实。

一、客户端软件

请大家告诉我Windows平台上有哪个流行的客户端软件是C#做的？

微软自家客户端：word, access, excel, outlook，IE，powerpoint, msnmessager，mediaplayer, groove, onenote, project, security essentials……
国外软件客户端：firefox, google chrome, photoshop, dreamweaver, illustrator, autodesk,quicktime,safari, ultraedit, adobe reader, acdsee…….
国内客户端：qq及各个家族产品, 迅雷，360，flashget, Foxmail，暴风影音，金山词霸，优化大师，傲游，电驴，pplive，ppstream，阿里旺旺，飞信（以前用过C#开发，后来受不了改回C++了）……..

任何一个领域，大家能找出哪怕1-5款在全世界或中国流行的客户端软件是用C#写的吗？？？请反方同学回答该问题。

其实不止飞信，firelong好几个朋友在腾讯、金山等公司做研发工作，他们都仔细评估过C#做客户端的性能问题，最后得出来的结论无一不是放弃C#。特别搞的是其中有一个公司的首席架构师就是从微软总部挖过来的，大家都以为他最支持C#，没想到他否定C#否定的最厉害。

就连VS 2010（这个就算我们程序员自己的客户端吧）也是C/C++做的（别把用.net搞了一点界面就说VS是.net做的，vs用.net做的少的可怜的代码量可以从GAC这里C:\Windows\assembly看microsoft.visualstudio开头的部分来得出自己的结论）

至于Windows操作系统——这算最大的客户端了吧！我压根就没期望这辈子能看到它用.NET开发！参见李开复博客：http://blog.sina.com.cn/s/blog_475b3d560100h4il.html　，注意其中几句话:

1. “盖茨定位的Windows Vista的三大目标是：支持新语言C#，所有操作系统软件都改用C#来写。因为C#语言的运行较慢，但是开发速度很快，这样微软不会落后于多人参与的开源Linux操作系统的发展。”

2. “因为技术的瓶颈已经到了极限，很多总监看到这个设想就倒吸了几口凉气：“技术难度太高了！C#这么慢，怎么能做操作系统啊？数据库不够快啊？怎么可能当做档案系统？””

3. "经过了三年的奋力拼搏，微软视窗团队的工程师们都已经疲惫不堪。但是，Windows Vista的成功却似乎遥遥无期。其实灾难早就在酝酿，因为大家在一开始就知道，这个伟大的计划实现起来，其执行难度实在是太大了!"

目前，我所知道的使用.NET做的算个稍微有点规模、有点含量的客户端，也就是Expression Studio（微软自己用WPF开发的）——firelong孤陋寡闻，如果大家知道更多的，请指出。千万别拿codeplex里面的玩具软件说事！你看看那里的软件除了将程序员作为用户，有多少软件是为真实的用户写的？别说.NET出来得晚，很多软件还没来得及用.NET做。.NET从2000年开始推出，到今天已经10年了，能干的话早该干了！

我本以为Expression Studio微软会用什么C#性能提升秘籍来搞，提振大家对C#的性能信心，希望研究学习学习。但是我真正跑了几次就郁闷了，我估计它几年后的命运和Windows Vista差不多。

有人说只拿客户端软件说事，不公平。那么我们来拿网站（当今世界上对人类最重要的软件就是网站了，对吧！）说说。

二、互联网软件

大家可以到这里来看：http://www.alexa.com/topsites 　Alexa全球前500大的网站，请数一数其中除了微软自己的网站为了dogfood的广告外，有几个是.NET开发的？——何况即便是微软自己的网站，也只是部分地用了.NET。

或者不相信Alexa的话，到这里：http://www.google.com/adplanner/static/top1000/　看看google对全球前1000名的网站排名中，数一数有几个是.NET开发的？

如果你懒得看Alex或者Google的排名。我在这里贴出一些典型的网站，大家看看：

google.com，facebook.com，youtube.com，yahoo.com，live.com，wikipedia.org，baidu.com，blogger.com，msn.com，qq.com，twitter.com，yahoo.co.jp，google.co.in ，taobao.com，google.de ，google.com.hk ，wordpress.com，sina.com.cn，amazon.com ，google.co.uk，ebay.com，bing.com，163.com，youku.com，sohu.com，tudou.com，sogou.com，hao123.com，tianya.cn，kaixin001.com，alibaba.com………

你可别说其中用了一个Silverlight插件，就说那个网站是.NET开发的！

有人又说了，你别光拿用户看得见，摸得着的软件说事啊，C#做了好多用户看不见的软件啊。那我们来看看用户看不见的软件中最关键的部分：服务器软件。

三、服务器软件

１. 微软自家服务器：biztalk, sharepoint, exchange, ISA, OCS, Sql server……

２. 其他厂商的：oracle, websphere, weblogic, mysql, Sybase, db2, aphache, vmware……

行了不用把省略号写下去了吧。国内厂商，对不起这块没什么牛叉的服务器。

写到这里，我的问题出来了：C#自2000年问世以来，在全世界或者全中国，到底搞出来了几个响当当的，能拿出手的，亿万用户喜闻乐见的软件了？　别说C#还年轻，10年在技术界算老人了！　我相信立即会有一大堆人怒吼：企业应用啊！这就对了，firelong给企业应用的解释就是“即便性能不咋样，客户也可以接受的软件叫企业应用！”

四、给老赵的问题

最后一个问题提给老赵，老赵不是最近去了盛大吗？仍然在写.NET吧？老赵可不可以告诉大家盛大的核心游戏平台上的软件（服务端、或者客户端都可）是.NET写的吗？　如果是，我佩服五体投地。

如果不是，老赵能否向盛大CTO建议采用.NET来写盛大的游戏平台（服务端、或者客户端都可）。老赵在其中用linq给排排序（多优雅啊！），用reflection给动态加载加载（多灵活啊！），用dynamic和其他软件互操作操作（多方便啊！），用attribute给类标记标记（多曼妙啊！），用jit编译器让盛大的游戏跨跨平台（多牛叉啊！）？？？？？？？

希望老赵不要回避这个真正的问题，千万别说游戏平台是系统内核底层应用，所以没有用C#——人家safe360是系统内核底层级软件，游戏软件可不是，游戏软件是典型的高级软件，游戏场景里面一大堆一大堆的object，不是正符合老赵等.NET拥趸口口声声的高级抽象吗？？？

如果老赵在盛大写的不是游戏平台上的软件，那么firelong烦请老赵告诉.NET社区自己在盛大写的软件是什么？很senior很senior的企业应用吧:)。

最后结语

所有所有这些软件压根没有用C#，或者经过调研、或者经过实际部署应用，但最后都放弃了C#的原因是什么？？？性能！性能！性能！

去年在上海参加.NET技术大会碰见.NET技术的大佬Jeffrey Richter，在论坛阶段我问了Jeffrey Richter两个问题：“1. .NET性能什么时候才能提上来？ 2. 微软为什么自己的绝大多数软件都不用.NET开发？”　Jeffrey Richter回答“1. 我相信我有生之年能看到 2. 微软自己主要用C/C++，但是鼓励开发者使用C#”。

听到Jeffrey Richter这两个回答，firelong当时有两个感想：

１. Jeffrey Richter看上去还很年轻，有生之年是１万年吗，兄弟们等得起吗（技术行业１０年光景相当于１万年！不知道要埋葬多少技术！）

２. 微软真伟大，难的都留给自己，容易的都留给开发者，真伟大啊真伟大！

我想写到这里，大家应该理解我第一个帖子的缘由了。

醒醒吧，朋友们，别再在老赵们编织的“新功能！新功能！再来一个新功能！cool，cool，很cool！”的童话中写代码了，真正牛叉的编程语言就要编写出像IE、adobe reader，facebook，QQ这样亿万人使用的牛叉的软件出来！

如果你说用C#开发你们公司一个小asp.net网站，或者几百人使用的什么企业应用（firelong太讨厌企业应用这个词了，不就是读读数据库吗，搞那么神乎其神干嘛！），你说.NET性能很好，那我没话说。

但是，你要开发成千上百万，甚至几亿、几十亿用户都使用的软件、网站、或者服务器、中间件，你还坚持使用C#开发，除非你自己做老板！不过请记住：Larry Page，Sergey Brin，Mark Zuckerberg，JeffBezos ，Jack Dorsey、李彦宏，马云，马化腾，丁磊不会比你傻。

好了，Firelong本帖已经摆完了事实。请大家也先摆事实开始来PK。在PK之前希望大家遵循前贴：技术社区辩论的Guidlines & Patterns之倡议（http://www.cnblogs.com/firelong/archive/2010/06/21/1762054.html）。

下一帖firelong将“讲原理”，即解释C#性能为什么这么慢（也就是firelong最开始的帖子希望C#砍掉的那些语言构造存在什么样的性能问题）——firelong在项目中研究这些个问题2年多了，性能优化技巧也用了很多了，将在下帖中一一列出。

firelong已经酝酿好了，只待这个帖子供大家pk充分后再下笔。Firelong应该会在１星期内再写下一帖：C#会重蹈覆辙吗？系列之2：论C#性能问题之原理。

谢谢等待！

本文链接