为什么C#运行速度比较慢?

我想那就是因为他封装成“大众型”的库,很多操作都非常仔细的处理,但我们很多时候根本不用考虑那么多。

因为这种“浪费的”操作使得他运行慢一点。当然,即时编译执行方式应该才是主要的因素。但这种执行上的浪费也是让人不爽的。就像美国人都觉得UNICODE编码不爽,因为他们仅需要ASCII码就够了,而UNICODE却无缘无故让他们的文档增加了一倍的空间!

参见一个操作,

 

Code

 

调用TryParse试图翻译true

 

Code

 

上面的代码来自System.Boolean类。前面的忽略字符大小写的比较是必须的,而后面的空白字符感觉就有些多余了。

因为这些函数都是内部使用,自己写的代码基本不会多写空白字符的,比如不会故意写成"trUe  "这种,而很多人还很喜欢每个字符串后面来个Trim()感觉是自己代码很安全,而他不知道这些代码99%的情况都不会有实际效用但反而增加执行时间……

就相当于一个火车站要过10个门才能到站台上车,在保证所有人只能从一个入口进入的前提下仅需要在那个唯一入口检票即可。不用每过一个门就要检一次!

为了更高效率,可以不做Trim操作,"True","False"之外的"  True "之类的就报异常,在发布之前就如果有异常就可以即时改正。真正必须的Trim只要在对外接口处(比如用户界面)上来一下就OK了。

 

或许还有人觉得一个Trim不会消耗多少吧?

不多说,看代码,System.String.Trim函数

 

Code

 

在return时调用 System.String.TrimHelper函数

 

TrimHelper

 

在最后return时调用System.String.InternalSubString

 

InternalSubString

在这个函数中会调用string.FastAllocateString

 

string.FastAllocateString

 

 结束语

看见上面这么多函数调用,以后是不是也会对效率有些感觉了呢?其实在对效率要求不高时这个是不用考虑的。

或许是我现在一直在写C++程序的缘故吧,对效率看得很重。加之最近一个项目服务端要用C#写,要维护上千个客户端。很多时候需要同时对多个客户端进行通信和大数据量处理同时接收并处理(70kb 每帧* 2 帧 * 并行客户端数目 / 秒)数据。

哎,不知道那些家伙怎么想的,非要我用C#写服务端,而客户端是之前我用C++写的。O(∩_∩)O~ 奇怪吧?

 

posted @ 2009-03-08 11:52  eager eagle  阅读(10254)  评论(36编辑  收藏  举报