博客园-Cavingdeep的技术专栏

用metaclass实现AOP风格的Profiler

Cavingdeep — Tue, 22 Aug 2006 02:36:00 GMT

阅读: 2434 评论: 4 作者: Cavingdeep 发表于 2006-08-22 10:36 原文链接

以下是一段通过metaclass实现Profiler的Python代码，很简单，功能不多，目的是为了展示Python的meta programming的能力，这种能力，无疑是很实用的，而且可以将AOP的方面（aspect）概念发挥的很好！下面的Profiler类（metaclass）就可以将方法的profiling在不同的类中复用。

class Profiler(type):
    def __new__(mcl, name, bases, dict):
        from time import clock
        from types import FunctionType

        def timing(func):
            def wrapper(*args, **kwds):
                start = clock()
                value = func(*args, **kwds)
                end = clock()
                print func.__name__, 'takes', (end - start), 'seconds'
                return value
            return wrapper

        for attr, value in dict.iteritems():
            if isinstance(value, FunctionType):
                dict[attr] = timing(value)

        return super(Profiler, mcl).__new__(mcl, name, bases, dict)

class A(object):
    __metaclass__ = Profiler

    def foo(self):
        total = 0
        for i in range(100000):
            total = total+1
        print total

    def foo2(self):
        from time import sleep

        total = 0
        for i in range(100000):
            total = total+1
            sleep(0.0001)
        print total

def main():
    a = A()
    a.foo()
    a.foo2()

if __name__ == '__main__':
    main()

此篇为抛砖引玉，希望大家能制作出更多更强的metaclass来，然后不妨与我们分享！:)

评论: 4　查看评论　发表评论

最新新闻：
· 知名扩展 Firebug 的简化版登陆 Chrome(2010-02-09 22:59)
· Google 悄悄地启用 1e100.net，打枪地不要(2010-02-09 22:57)
· 从 Google 代码库找到的好东西(2010-02-09 22:46)
· 苹果在线商店临时关闭或将推新Macbook(2010-02-09 22:39)
· 豆瓣网推出豆瓣电台iPhone客户端(2010-02-09 21:51)

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

Singleton implementation using metaclass

Cavingdeep — Tue, 22 Aug 2006 02:34:00 GMT

阅读: 1919 评论: 0 作者: Cavingdeep 发表于 2006-08-22 10:34 原文链接

这里是一段Python代码，展示了如何利用metaclass来实现一个通用的Singleton，这使任何一个class都可以简单的复用这一行为：

class Singleton(type):
    def __call__(cls, *args):
        if not hasattr(cls, 'instance'):
            cls.instance = super(Singleton, cls).__call__(*args)
        return cls.instance

class Cache(object):
    __metaclass__ = Singleton

def main():
    cache = Cache()
    cache.data1 = 1
    print 'data1 == %s' % cache.data1

    cache2 = Cache()
    cache2.data1 = cache2.data1 + 1
    print 'data1 is increased by 1.'
    print 'data1 == %s' % cache.data1

if __name__ == '__main__':
    main()

这是一个简单的meta programming的应用展示，展示了metaclass所蕴涵的强大的能力，只要想得到，metaclass可以实现各种各样用通常手法做不到或很难实现的功能。:D

评论: 0　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

初试IronPython与.NET的集成

Cavingdeep — Tue, 01 Aug 2006 03:06:00 GMT

阅读: 3518 评论: 5 作者: Cavingdeep 发表于 2006-08-01 11:06 原文链接

在得知IronPython如今已步入1.0 RC1后兴奋不已，赶快下载下来试用。虽说功能性变化不多（加入了试用性Python 2.5的语法支持:D），但稳定性如今已提高了不少，应该说可以用来投入正式使用了。:)

如何用好IronPython

翻看了一下Tutorials，发现和以前的内容差不多，按照Tutorials中的方法尝试了一下在C#中嵌入IronPython 代码，发现还很不错，最起码可行，虽然速度肯定没有用C#直接写出来的快（因为IronPython需要动态编译的缘故）。

好的，现在我们拥有了一项较稳定的可以投入使用的新技术了，但是如果没有市场，那么这个新技术是不能够生存的，所以我左思右想 IronPython在企业级开发中到底占了什么地位（因为我是做企业级开发的:)），有何等优势呢？通过分析现有IronPython的特征，我得到了一个结论，那就是它比较适合做脚本引擎或者简单的客户端。以下是我分析的IronPython的一些特征：

Python的语法，灵活性相当的高！
与.NET Framework的交互实现的非常的好，现在用Python的语法也可以用.NET的类库了。
在其他.NET语言中可以通过引用IronPython.dll来执行IronPython文件并且可以实现内存共享（在同一AppDomain中）。
纯IronPython程序启动非常慢。
由于IronPython的特殊性，它所编译出来的程序集中的成员并非你所想象的，所以不能够由其他程序集直接引用使用。这主要还是因为Python是一种动态类型语言，所以无法在编译时给予合适的静态类型（唯一合适的就是System.Object）。另外为了与CPython保持兼容性，IronPython也是以module为单位进行group的，也就是一个module被编译成一个类，这个module中的所有成员，包括class都被当作成员编译在这个类中。

基于以上一些IronPython现有的特征来看，我觉得它更适合使用.NET 程序集，而非为.NET程序提供功能（虽然也是可行的，也是我希望的），所以我建议将IronPython用作客户端以及脚本引擎一类的用途上，因为这类程序是属于consumer类的，它们使用现成的API，但是它们不为其他人提供新的API。

如何用IronPython为.NET程序提供API

读者可能会说我自相矛盾，刚刚才说过IronPython不适合用来提供API，怎么现在又提起这件事来了呢（唉，人本身就是一种很矛盾的生物）？！其实就像上面我在括号中提及的，利用IronPython的交互能力与语言的灵活性为我的.NET程序提供简化的解决方案是我的期望，虽然速度方面还不尽人意，但优化的空间永远都是存在的，我相信随着时间的推移IronPython会在性能方面做的更出色（从这方面来看我是个乐观主义者:D）。

为了简化主程序与IronPython文件的交互与维护难度，我决定将IronPython文件作为服务（service）来看待，IronPython所提供的每一个API就是一个独立的服务，每次需要使用这个服务的时候我只需向它发送相应的消息（message）即可，而它，会返回给我一个回应（response）如果有必要的话。我觉得这样做比较符合目前的SOA潮流。（如果你还不知道SOA是什么的话，一句话告诉你，它是一种企业级集成手段）

我的做法很简单，只是初步实现了一个对IronPython文件调用的封装，示例如下。

List<int> a = new List<int>();
a.Add(1);
a.Add(2);
a.Add(3);

List<int> b = new List<int>();
b.Add(4);
b.Add(5);
b.Add(6);

PyFacade<IList<IList<object>>> py =
    new PyFacade<IList<IList<object>>>();
py.PythonFile = "mayorThenTen.py";
py.Arguments.Add("listA", a);
py.Arguments.Add("listB", b);
py.Execute();

foreach (IList<object> tuple in py.Result) {
    Console.Write(tuple[0]);
    Console.Write(", ");
    Console.Write(tuple[1]);
    Console.WriteLine();
}

PyFacade的代码如下。

using System;
using System.Collections.Generic;

using IronPython.Hosting;

namespace Cavingdeep.Python {
   public class PyFacade<T> {
      public const string ResultVariableName = "_result_";

      private PythonEngine engine = new PythonEngine();

      private string pythonFile;
      private Result<T> result = new Result<T>();
      private IDictionary<string,object> args =
         new Dictionary<string,object>();

      public string PythonFile {
         get {return this.pythonFile;}
         set {this.pythonFile = value;}
      }

      public T Result {
         get {return this.result.Value;}
      }

      public IDictionary<string,object> Arguments {
         get {return this.args;}
      }

      public void Execute() {
         engine.Globals[ResultVariableName] = this.result;

         foreach (KeyValuePair<string,object> arg in this.args) {
            engine.Globals[arg.Key] = arg.Value;
         }

         engine.ExecuteFile(this.pythonFile);
      }
   }
}

Result的代码如下。

using System;

namespace Cavingdeep.Python {
   public class Result<T> {
      public T Value;
   }
}

mayorThenTen.py的代码如下，这是这个示例中用到的IronPython文件。

def mayorThenTen(a, b):
return [(x, y) for x in a for y in b if x + y > 5]

if globals().has_key('_result_'):
_result_.Value = mayorThenTen(listA, listB)

这里的这个PyFacade是个比较通用的与IronPython交互的接口类，在真正的应用中建议用强类型模式（强类型设计实践）加以封装以得到type safety等好处。

关于PyFacade是如何与IronPython文件交互一题，简单地说就是通过那个_result_变量，它会在IronPython文件中被赋值，这个值是外界可见的，也就是说IronPython文件的执行与当前程序是在一个AppDomain中的。有关这类知识感兴趣的读者可以去研究一下动态编译、加载与程序域（AppDomain）等知识。

评论: 5　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

Refactoring as a way to improve the existing design

Cavingdeep — Sat, 15 Jul 2006 01:04:00 GMT

阅读: 1053 评论: 1 作者: Cavingdeep 发表于 2006-07-15 09:04 原文链接

Share with you a refactoring web site maintained by the mighty 'Martin Fowler':

http://www.refactoring.com/

You can find up to 93 refactoring methods in the catalog of this web site, 21 more than listed in book . Understanding the importance of refactoring can help you write robust and mantainable code, an essential weapon for today's agile business.

评论: 1　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

用metaclass来实现AOP

Cavingdeep — Fri, 28 Apr 2006 01:05:00 GMT

阅读: 1209 评论: 0 作者: Cavingdeep 发表于 2006-04-28 09:05 原文链接

meta-programming是AOP实现的经常性手段，而这里要展示的，是利用Python的metaclass能力来实现 AOP。

当a的setx方法被调用时，会被“拦截”，先输出pre...然后是原始setx的方法调用，最后输出post...

class MetaAll(type):
   def __new__(mcl, name, bases, dict):
      def log(func):
         def f(*args, **kwds):
            print 'pre %s' % func.__name__
            value = func(*args, **kwds)
            print 'post %s' % func.__name__
            return value
         return f
      for attr, value in dict.iteritems():
         if attr.startswith('set'):
            dict[attr] = log(value)
      return super(MetaAll, mcl).__new__(mcl, name, bases, dict)

__metaclass__ = MetaAll

class A:
   def __init__(self):
      self.__x = 1

   def getx(self):
      return self.__x

   def setx(self, value):
      self.__x = value

a = A()
a.setx(2)
print a.getx()

看到那个__metaclass__变量了吗？如果你赋给它另外一个metaclass的话它会产生其他效应（我这里做的是 logging，其他的可能有例如timing、access control、transaction, etc.），这是魔法！^_^ 最魔力十足的地方是我甚至可以把一个metaclass传进模块中去，给__metaclass__动态的赋值（赋metaclass），这意味着我可以通过meta-programming动态的改变我程序的逻辑，或者不需要改动原有代码即可添加新功能（或修改）等特点！

整个演示就当作抛砖引玉吧，代码我就不细讲了，因为概念太复杂了，不是一两句能说得明白的。有兴趣的朋友可以研究一下Python。; -)

评论: 0　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

不该用Generics实现Abstract Factory的理由

Cavingdeep — Fri, 24 Mar 2006 02:24:00 GMT

阅读: 1588 评论: 16 作者: Cavingdeep 发表于 2006-03-24 10:24 原文链接

最近在与Ninputer争执.NET与Java的泛型特点，他的意见是.NET的Generics要更强（实现层面与语法层面两个层面），我的意见是Java的Generics的语法层面要更强（语法层面的强主要是指易用性）。他让我看了一篇用.NET Generics实现的Abstract Factory的文章http://blog.joycode.com/ninputer/archive/2006/01/12/70313.aspx，说如果用Java就会遇到很多麻烦。因为我也是初学Java的Generics，所以比较感兴趣这个话题，看了一下文章后做了一些实现后得出了以下一些结论。

该不该使用Generics实现Abstract Factory？

我的意见是不应该，理由如下：

具体创建对象的时候，也就是在ConcreteFactory中，不是所有情况都是简单地一个new操作就算是创造对象了，就像它的名字所示那样，具体对象具体操作，这里不能泛化，一定要根据具体类型来实现对象创建。
就像许多人提到的，到底用多少个type variable才算合适呢？AbstractFactory, AbstractFactory ??? 简单地说，Abstract Factory是不能够定量的，目前.NET与Java的泛型都不能实现这点。

Java的泛型真的那么弱吗？如果要实现定量的Abstract Factory真的很难吗？

我的答案是否，实际上，我觉得用Java的语法无论在实现上的阅读与易用性都要比.NET的语法强。下面是我给出的Abstract Factory的实现，虽然我说过，用Generics实现Abstract Factory并不合适。

interface Processor {}

interface Ram {}

class PentiumProcessor implements Processor {}

class DDRRam implements Ram {}

interface AbstractFactory<PA, PB> {
   PA createA();
   PB createB();
}

class IntelFactory implements AbstractFactory<PentiumProcessor, DDRRam> {
   public PentiumProcessor createA() {
      // 一切特化且可在这里实现。
      return new PentiumProcessor();
   }

   public DDRRam createB() {
      // 一切特化且可在这里实现。
      return new DDRRam();
   }
}

// 使用
AbstractFactory extends Processor, ? extends Ram> factory =
   new IntelFactory();

Processor processor = factory.createA();
Ram ram = factory.createB();

以上代码并没有运用不必要的TypeToken，而且也没有实例化时特化的问题，但是仍然没有解决Abstract Factory的量的问题。可以看出，这段代码非常的简洁，我觉得这段代码真正突出了Generics的优点：泛化类型，而没有做不应该做的过多的事情（比如泛化本来应该是特化的东西）。

注意Java的Generics语法是可以使用wildcard的（?），这是.NET所没有的。wildcard的特点之一就是能够在变量声明中使用，这是很重要的一大特色。

评论: 16　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

新兴XML处理方法VTD-XML介绍

Cavingdeep — Wed, 15 Mar 2006 03:49:00 GMT

阅读: 4612 评论: 26 作者: Cavingdeep 发表于 2006-03-15 11:49 原文链接

序言

本文所提及的VTD-XML并非本文作者原创，作者只是对它进行介绍。

问题

通常当我们提起XML的使用时，最头痛的部分便是XML的verbosity与XML的解析速度，当需要处理大XML文件时这个问题便变得格外严重。我在这里提及的，便是如何优化XML处理速度的话题。

当我们选择处理XML文件的时候，我们大致上有两种选择：

DOM，这是W3C的标准模型，它将XML的结构信息以树形的方式构建，提供了遍历这颗树的接口与方法。
SAX，一种低级的parser，逐元素的向前只读处理，不含有结构信息。

以上两种选择都各有利弊，但是都不是特别好的解决方案，它们的优缺点如下：

DOM

优点：易用性强，因为所有的XML结构信息都存在于内存中，并且遍历简单，支持XPath。
缺点：Parsing速度太慢，内存占用过高（原文件的5x~10x），对于大文件来说几乎不可能使用。

SAX

优点：Parsing速度快，内存占用不与XML的大小相联系（可以做到XML涨内存不涨）。
缺点：易用性差，因为没有结构信息，并且无法遍历，不支持XPath。如果需要结构的话只能读一点构造一点，这样的可维护性特别的差。

我们可以看出，基本上DOM与SAX是正好相反的两个极端，但是任何一个都不能很好的满足我们的大部分要求，我们需要找出另外一种处理方法来。注意XML的效率问题并不是XML本身的问题，而是处理XML的Parser的问题，就像我们在上面看到的两种方法有不同的效率权衡一样。

思考

我们很喜欢类似DOM的使用方法，因为我们可以遍历，这意味着可以支持XPath，大大增强了易用性，但是DOM的效率很低。就像我们已经知道，效率问题出在处理机制上。那么，DOM到底有哪些方面影响了它的效率呢？下面让我们来做一个全面的解剖：

在当今大多数基于虚拟机（托管，或任何类似机制）技术的平台下，对象的创建销毁是一个耗时的作业（这里值得主要是Garbage Collection的耗时），DOM机制中所运用的大量的对象创建销毁无疑是影响其效率的原因之一（会引发过多的Garbage Collection）。
每个对象都会额外有32bits用来存储它的内存地址，当像DOM一样拥有大量对象的时候这个额外开支也是不小的。
引起以上两个问题的最主要的效率问题在于，DOM与SAX都是extractive parsing模式，这种解析模式注定了DOM与SAX都需要大量的创建（销毁）对象，引起效率问题。所谓的extractive parsing就是说在解析XML时，DOM或SAX会提取一部分原文件（一般来说是一个字符串），然后在内存中进行解析构建（输出自然就是一个或一些对象了）。拿DOM这个例子来说，DOM会将每一个element, attribute, processing-instruction, comment等等都解析成对象并给与结构，这就是所谓的extractive parsing。
由extractive的问题带来的另一个问题便是更新效率，在DOM中（SAX因为不支持更新所以根本不提它），每一次需要做改动时，我们要做的就是将对象的信息再解析回XML的字符串，注意这个解析是个完整的解析，也就是说，原文件并没有被利用，而是直接将DOM模型重新完整解析成XML字符串。换句话讲，也就是DOM并不支持Incremental Update（增量更新）。
另一个很可能不被注意到的“小”问题便是XML的编码，无论是何种解析方法都需要能够处理XML的编码，也就是说，在读取的时候解码，在写入的时候编码。DOM的另一个效率问题便是当我对于一个大XML只想做很小的一块儿修改的时候它也必须首先将整个文件进行解码，然后构建结构。无形中又是一个开销。

让我们来总结一下问题，简单的讲DOM的效率问题主要出在它的extractive parsing模式上（SAX也是一样，有同样的问题），由此引发了一系列相关问题，如果可以击破这些效率瓶颈的话那么可以想象XML的处理效率将进一步的得到提高。如果XML的易用性与处理效率得到飞跃性的提高的话，那么XML的应用范围，应用模式将得到更一步的升华，或许由此可以产生出许许多多精彩的以前连想都没有想过的基于XML的产品来。

出路

VTD-XML便是对以上问题的思考后给出的答案，它是一个non-extractive XML parser，由于它出色的机制，很好的解决（避免）了上面所提出的各种问题，并且还“顺便”带来了non-extractive的其他好处，像快速的解析与遍历、XPath的支持、Incremental Update等等。我这里有一组数据，取自于VTD-XML的官方网站：

VTD-XML的解析速度是SAX（with NULL content handler）的1.5x~2.0x。With NULL content handler的意思就是说SAX解析中没有插入任何额外的处理逻辑，也就是SAX的最高速度。
VTD-XML的内存占用是原XML的1.3x~1.5x（其中1.0x的部分是原XML，0.3x~0.5x是VTD-XML占用的部分），而DOM的内存占用则是原XML的5x~10x。举一个例子，如果一个XML的大小是50MB，那么用VTD-XML读取进来内存占用会在 65MB~75MB之间，而DOM的内存占用则会在250M~500MB之间。基于这个数据用DOM处理大的XML文件几乎是不可能的选择。< /li>

你可能会觉得不可思议，真的可以做出比DOM易用性还好，比SAX还快的XML解析器吗？别急着下定论，还是来看看VTD-XML的原理吧！

基本原理

就像大多数好的产品一样，VTD-XML的原理并不复杂，而是很巧妙。为了实现non-extractive这个目的，它将原XML文件原封不动的以二进制的方式读进内存，连解码都不做，然后在这个byte数组上解析每个element的位置并把一些信息记录下来，之后的遍历操作便在这些保存下来的record上进行，如果需要提取XML内容就利用record中的位置等信息在原始byte数组上进行解码并返回字符串。这一切看起来都很简单，但是，这个简单的过程确有多个性能细节在里边，并且隐藏了若干个潜在的能力。下面我们首先来描述一下各个性能细节：

为了避免过多的对象创建，VTD-XML决定采用原始的数值类型作为record的类型，这样就可以不必用heap。VTD-XML 的record机制就叫做VTD（Virtual Token Descriptor），VTD将性能瓶颈在tokenization阶段就解决掉了真的是很巧妙很用心的做法。VTD是一个64bits长度的数值类型，记录了每个element的起始位置（offset），长度（length），深度（depth）以及token的类型（type）等信息。
注意VTD是固定长度的（官方决定用64bits），这样做的目的就是为了提高性能，因为长度固定，在读取，查询等操作的时候格外的高效（O(1)），也就是可以用数组这种高效的结构来组织VTD大大减少了因为大量使用对象而产生的性能问题。
VTD的超能力（一点都不夸张地说）就在于它能够将XML这种树形的数据结构简单的变换成对一个byte数组的操作，任何你能想象到的对于byte数组的操作都可以应用在XML上了。这是因为读取进来的XML是二进制的（byte数组），而VTD则记录了每个element的位置等访问用信息，当我们找到要操作的VTD的时候，只要用offset与length等信息就可以对原始byte数组进行任何操作，或者可以直接对VTD进行操作。举例来说，我想在一个大XML中找出一个element并删除它，那么我只需要找到这个element的VTD（遍历方法稍候再讲），将这个VTD从 VTD数组中删除，然后再利用所有的VTD写出到另一个byte数组中就可以了，因为删除的VTD标明了要删除的element的位置，所以在新写入的 byte数组中就不会出现这段element了，用VTD 写入新的byte数组实际上就是一个byte数组的拷贝，其效率相当的高，这就是所谓的增量更新（incremental update）。

关于VTD-XML的遍历方式，它采用了LC (Location Cache)，简单地说就是将VTD以其深度作为标准构建的一个树形的表结构。LC的entry也是64bits长的数值类型，前32bits代表一个 VTD的索引（index），后32bits代表了这个VTD的第一个child的索引。利用这些信息就可以计算出任何一个你想要到达的位置了，关于具体的遍历方法请参看官方网站的文章。基于这种遍历方式的VTD-XML有与DOM不同的操作接口，这是可以理解的，并且，VTD-XML的这种遍历方式可以在最少的几步内将你带到你所需要的地方去，遍历的性能十分突出。

总结

就像你上面看到的，VTD-XML有着迷人的特性，而如今的1.5版本中已经加入了XPath的支持（只要可以遍历，就可以支持 XPath，这是早晚的事:-)），它的实用性已经超越了当今我们所想象的范围了。另一个VTD-XML的超能力，就是基于它现在的处理方式，完全可以支持将来的Binary XML标准，并通过Binary化将XML的应用推向更高一层楼！这也是我目前所期待的！:-)

不过，VTD-XML仍然有许多需要改进与完善的地方，这方面值得我们努力与探讨。

顺便提一下，VTD-XML是开源项目（GPL），目前有Java、C两种平台支持。如果你想在.NET试一试的话建议你使用IKVM（BSD style license）将VTD-XML转换成.NET程序集，相信你会喜欢上它的！;-)

评论: 26　查看评论　发表评论

编辑推荐：2010年2月编程语言排行榜

网站导航：博客园首页个人主页新闻闪存小组博问社区知识库

Performance Tips I

Cavingdeep — Fri, 16 Dec 2005 05:39:00 GMT

阅读: 1538 评论: 21 作者: Cavingdeep 发表于 2005-12-16 13:39 原文链接

假如所有的人都很在意高性能代码的话，那么我的这篇Blog就没有意义了。我希望能够给出一些有意义的性能提示，这些是我们日常编码工作中总会碰到的，所以对这些小tips漠不关心只会日益加深对你代码的伤害，而且做Review的时候也会很不体面，老实说，一个人写的代码确切地反映了这个人的能力与个性，对于经常看不同代码的我们来说，这并不是胡说的，我们有确切的体会。

首先值得一提的是，如果你的程序有性能问题，请不要首先在代码中找，因为一般情况下，大的性能问题都发生在架构与设计上，架构与设计的性能问题是在代码层次解决不了的，影响面也很广。这篇文章不会告诉你如何在架构与设计中找性能问题，或者架构与设计的性能提示。这篇文章只是在编码层次上给这个层次的性能提示，虽然比不上架构与设计的性能优化，但是如果不注意也还是会带来显著的性能影响的。

我会以总结的方式列出每条我能想到的性能提示来，并解析为什么会这样，希望对读者有用。

Resource Management（资源管理）

作为任何一个程序，都需要考虑它所能使用的资源界限以及它目前使用的资源状况。假设一个程序只被允许使用100MB内存，但是它在执行某个大任务时内存占用却达到了400MB，那么这时你就会发现你有个不得不解决的大问题。任何硬件的资源都是有限的（不要跟我说SETI，没有几个程序是SETI类型的），作为程序，如何利用好这些有限的资源达到目的是任何一个开发人员不得不考虑的（不管你是架构师、设计师还是纯粹的Developer）。首先我们要知道所谓的资源其实可以分为几大类：

CPU
Memory
Disk I/O
Network I/O

为了有效的利用这些有限的资源，我们有时不得不针对资源管理做一些优化，下面的这些便是一些相关的tips。可能你会问：“资源的管理.NET下不是自动的嘛，不是有GC的嘛”，没错，GC是做资源管理的，但是这并不代表有GC我们就不用注意资源的使用了，因为GC的行为是固定的，所以我们可以针对GC的行为来为它优化。下面会有几条tips谈到。

只在你真正需要时分配内存。

为什么：

内存的过早分配会造成不必要的效率损失以及资源紧缺或者浪费。

不好的做法：

static Result Divide(double a, double b) {
   // Result对象过早的分配，当a/b发生异常时
   // 这个对象就白分配了，因为这个对象只有被
   // 方法返回才有意义。
   Result r = new Result();
   r.Value = a / b;

   return r;
}

好的做法：

static Result Divide(double a, double b) {
   double value = a / b;

   Result r = new Result();
   r.Value = value;

   return r;
}

尽可能早的释放资源。

为什么：

对于你已经确定不再需要的对象如果不尽早对其释放就有可能造成不必要的资源紧缺。

不好的做法：

static void Foo() {
   connection.Open();
   try {
      // Data operations

      // PostProcessing并不涉及数据库连接的使用，
      // 在处理PostProcessing的时候，一个宝贵的
      // 数据库连接资源就被这样白白的浪费了，如果
      // 这时有其他需要数据库连接的操作而它又
      // 没有可用连接那么就会引发timeout等等因数据库
      // 连接不足而产生的各种问题。
      PostProcessing();
   } finally {
      connection.Close();
   }
}

好的做法：

static void Foo() {
   connection.Open();

   try {
      // Data operations
   } finally {
      connection.Close();
   }

   PostProcessing();
}

不要使用Finalizer，除非是为了确保关键资源的正确释放。

为什么：

有Finalizer的对象需要两次GC才能被彻底回收，影响内存回收效率，第一次GC会执行Finalizer，第二次才会释放对象所占用的内存空间。

不好的做法：

~MyClass() {
// 影响资源回收的速度。
instanceNumber--;
}

好的做法：

不声明Finalizer。

对于拥有非托管资源的对象，一定要实现Disposable模式。

为什么：

实现了整个Disposable模式才能确保非托管资源会被正确释放（非托管资源不受GC管理，需手动释放），并且提供了手动释放的方法。

不好的做法：

// 拥有文件系统这种非托管资源，但是没有
// 定义关闭这个非托管资源的方法。
class TextFile {
   private FileStream fileStream;

   public string ReadLine() {

   }


}

好的做法：

class TextFile : IDisposable {
   private FileStream fileStream;

   public string ReadLine() {

   }



   public void Dispose() {
      this.Dispose(true);
   }

   protected virtual void Dispose(bool disposing) {
      if (disposing) {
         // 在这儿清理一切托管的与Disposable的托管
         // 成员。
         if (this.fileStream != null) {
            this.fileStream.Close();
            this.fileStream = null;
         }

         // 因为我们已经显示地清理了资源，所以不再需要
         // Finalizer了，有它会影响效率。
         GC.SupressFinalize();
      }

      // 在这儿清理一切非托管资源。

      // 如果有基类，应在这里调用基类的Dispose。这样做
      // 是因为清理顺序应该是首先清理自身的一切资源，
      // 然后基类清理自身的一切资源，依此类推。
   }

   ~TextFile() {
      this.Dispose(false);
   }
}

在Dispose方法中调用GC.SupressFinalize。

为什么：

就像前面提到的，有Finalizer会影响回收效率，既然你都已经手动Dispose了，那么干吗还要Finalizer呢（注意Finalizer的作用应该限制在调用Dispose上）？

不好的做法：

请参照上一示例。

好的做法：

请参照上一示例。

避免延长存活期短的对象的寿命。

为什么：

存活期短的对象会被GC优先回收，回收的效率更高。如果无谓的延长它的寿命的话再次回收它时效率会更低，而且它也会被更慢的回收。GC回收时是按照generation来回收，新创建的对象都在generation 0中，GC回收时先回收generation 0中的对象，如果回收到足够的空间那么将不再继续回收，如果不够再在generation 1中回收，依此类推，最高的generation是2，每次回收后存活下来的对象将升至更高级别的generation，从0到1再到2。寿命短的对象很自然的会在generation 0中回收，但如果延长它的寿命的话它就很可能会升至generation 1，这样一来就没有generation 0的回收效率了。

不好的做法：

static void Foo() {
   string lines = "";
   for (int i = 1; i <= 10; i++) {
      // 每次lines的临时内容都不能第一次就被
      // 回收，因为lines有引用，所以这个临时对象
      // 会被promote为更高的generation，这样无形
      // 中就对GC的工作压力产生了巨大的影响。
      lines += "Line " + i + Environment.NewLine;
   }
   Console.Write(lines);
}

好的做法：

在这个特殊的例子中应使用StringBuilder避免临时对象的产生。

注意字符串连接的做法。

为什么：

不同的字符串连接需采用不同的方法，这样才能达到不损伤性能。有以下几种情况：

连接string literal：采用+符号连接，编译时编译器会将这些被连接的literals自动写成一个literal。
一次性连接已知数量的literal与/或变量：采用+符号连接，因为这个连接其实只是一个String.Concat，没有临时对象产生。
多次连接或者连接未知数量的literal或变量：采用StringBuilder来追加内容，避免临时对象的产生。

不好的做法：

void Foo() {
   // Case 1. 连接literals使用StringBuilder
   // 要比用+号性能低很多。
   StringBuilder builder = new StringBuilder();
   builder.Append("This is a very very ");
   builder.Append("very very very very ");
   builder.Append("very very very very ");
   builder.Append("very very very very ");
   builder.Append("long string literal");
   Console.Write(builder.ToString());

   // Case 2. 一次性连接已知数量就足够的情况下
   // 就不必使用StringBuilder了。
   StringBuilder builder2 = new StringBuilder();
   builder2.Append("Literal variable newline");
   builder2.Append(tempVar);
   builder2.Append(Environment.NewLine);
   Console.Write(builder2.ToString());

   // Case 3.1. 这里每次+=都会产生两个临时字符串
   // 对象，大大增加了GC的负担，严重影响了效率。
   string lines = "";
   for (int i = 1; i <= 10; i++) {
      lines += "Line " + i + Environment.NewLine;
   }
   Console.Write(lines);

   // Case 3.2. 这里每次Append时会由+引起临时字符串
   // 对象，影响效率。
   StringBuilder builder = new StringBuilder();
   for (int i = 1; i <= 10; i++) {
      builder.Append("Line " + i + Environment.NewLine);
   }
   Console.Write(builder.ToString());
}

好的做法：

void Foo() {
   // Case 1.
   string longLiteral =
      "This is a very very " +
      "very very very very " +
      "very very very very " +
      "very very very very " +
      "long string literal";
   Console.Write(longLiteral);

   // Case 2.
   string line =
      "Literal variable newline" +
      tempVar + Environment.NewLine;
   Console.Write(line);

   // Case 3.
   StringBuilder builder = new StringBuilder();
   for (int i = 1; i <= 10; i++) {
      builder.Append("Line ");
      builder.Append(i);
      builder.Append(Environment.NewLine);
   }
   Console.Write(builder.ToString());
}

不采用ToUpper或ToLower进行字符串不区分大小写的对比。

为什么：

ToUpper与ToLower每次对比时会产生临时对象，影响性能。改用String.Compare，这不会有临时对象产生，而且还可以根据文化进行对比（或文化中立的进行对比）。

不好的做法：