.NET程序性能的基本要领

2014-8-27 11:29| 发布者: joejoe0332| 查看: 5059| 评论: 0|原作者: 寒江独钓|来自: 寒江独钓的博客

摘要: Bill Chiles（Roslyn编译器的程序经理)写了一篇文章《Essential Performance Facts and .NET Framework Tips》，知名博主寒江独钓对该文进行了摘译，文中分享了性能优化的一些建议和思考，比如不要过早优化、好工具 ...

例2 枚举类型的装箱

　　下面的这个例子是导致新的C# 和VB编译器由于频繁的使用枚举类型，特别是在Dictionary中做查找操作时分配了大量内存的原因。

[js] view plaincopy
public enum Color { Red, Green, Blue }  
public class BoxingExample  
{  
    private string name;  
    private Color color;  
    public override int GetHashCode()  
    {  
        return name.GetHashCode() ^ color.GetHashCode();  
    }  
}  

　　问题非常隐蔽，PerfView会告诉你enmu.GetHashCode()由于内部实现的原因产生了装箱操作，该方法会在底层枚举类型的表现形式上进行装箱，如果仔细看PerfView，会看到每次调用GetHashCode会产生两次装箱操作。编译器插入一次，.NET Framework插入另外一次。

解决方法：

　　通过在调用GetHashCode的时候将枚举的底层表现形式进行强制类型转换就可以避免这一装箱操作。

[js] view plaincopy
((int)color).GetHashCode()  

　　另一个使用枚举类型经常产生装箱的操作时enum.HasFlag。传给HasFlag的参数必须进行装箱，在大多数情况下，反复调用HasFlag通过位运算测试非常简单和不需要分配内存。

　　要牢记基本要领第一条，不要过早优化。并且不要过早的开始重写所有代码。需要注意到这些装箱的耗费，只有在通过工具找到并且定位到最主要问题所在再开始修改代码。

字符串

　　字符串操作是引起内存分配的最大元凶之一，通常在PerfView中占到前五导致内存分配的原因。应用程序使用字符串来进行序列化，表示JSON和REST。在不支持枚举类型的情况下，字符串可以用来与其他系统进行交互。当我们定位到是由于string操作导致对性能产生严重影响的时候，需要留意string类的Format(),Concat(),Split(),Join(),Substring()等这些方法。使用StringBuilder能够避免在拼接多个字符串时创建多个新字符串的开销，但是StringBuilder的创建也需要进行良好的控制以避免可能会产生的性能瓶颈。

例3 字符串操作

在C#编译器中有如下方法来输出方法前面的xml格式的注释。

[js] view plaincopy
public void WriteFormattedDocComment(string text)  
{  
    string[] lines = text.Split(new[] {"\r\n", "\r", "\n"},  
        StringSplitOptions.None);  
    int numLines = lines.Length;  
    bool skipSpace = true;  
    if (lines[0].TrimStart().StartsWith("///"))  
    {  
        for (int i = 0; i < numLines; i++)  
        {  
            string trimmed = lines[i].TrimStart();  
            if (trimmed.Length < 4 || !char.IsWhiteSpace(trimmed[3]))  
            {  
                skipSpace = false;  
                break;  
            }  
        }  
        int substringStart = skipSpace ? 4 : 3;  
        for (int i = 0; i < numLines; i++)  
            Console.WriteLine(lines[i].TrimStart().Substring(substringStart));  
    }  
    else  
    {  
        /* ... */  
    }  
}  

　　可以看到，在这片代码中包含有很多字符串操作。代码中使用类库方法来将行分割为字符串，来去除空格，来检查参数text是否是XML文档格式的注释，然后从行中取出字符串处理。

　　在WriteFormattedDocComment方法每次被调用时，第一行代码调用Split()就会分配三个元素的字符串数组。编译器也需要产生代码来分配这个数组。因为编译器并不知道，如果Splite()存储了这一数组，那么其他部分的代码有可能会改变这个数组，这样就会影响到后面对WriteFormattedDocComment方法的调用。每次调用Splite()方法也会为参数text分配一个string，然后在分配其他内存来执行splite操作。

　　WriteFormattedDocComment方法中调用了三次TrimStart()方法，在内存环中调用了两次，这些都是重复的工作和内存分配。更糟糕的是，TrimStart()的无参重载方法的签名如下：

[js] view plaincopy
namespace System  
{   
    public class String   
    {   
        public string TrimStart(params char[] trimChars);  
    }  
}  

　　该方法签名意味着，每次对TrimStart()的调用都回分配一个空的数组以及返回一个string类型的结果。

　　最后，调用了一次Substring()方法，这个方法通常会导致在内存中分配新的字符串。

解决方法：

　　和前面的只需要小小的修改即可解决内存分配的问题不同。在这个例子中，我们需要从头看，查看问题然后采用不同的方法解决。比如，可以意识到WriteFormattedDocComment()方法的参数是一个字符串，它包含了方法中需要的所有信息，因此，代码只需要做更多的index操作，而不是分配那么多小的string片段。

　　下面的方法并没有完全解，但是可以看到如何使用类似的技巧来解决本例中存在的问题。C#编译器使用如下的方式来消除所有的额外内存分配。

[js] view plaincopy
private int IndexOfFirstNonWhiteSpaceChar(string text, int start)  
{  
    while (start < text.Length && char.IsWhiteSpace(text[start]))   
        start++;  
    return start;  
}  
  
private bool TrimmedStringStartsWith(string text, int start, string prefix)  
{  
    start = IndexOfFirstNonWhiteSpaceChar(text, start);   
    int len = text.Length - start;   
    if (len < prefix.Length) return false;  
    for (int i = 0; i < len; i++)  
    {  
        if (prefix[i] != text[start + i])   
            return false;  
    }  
    return true;  
}  

　　WriteFormattedDocComment() 方法的第一个版本分配了一个数组，几个子字符串，一个trim后的子字符串，以及一个空的params数组。也检查了”///”。修改后的代码仅使用了index操作，没有任何额外的内存分配。它查找第一个非空格的字符串，然后逐个字符串比较来查看是否以”///”开头。和使用TrimStart()不同，修改后的代码使用IndexOfFirstNonWhiteSpaceChar方法来返回第一个非空格的开始位置，通过使用这种方法，可以移除WriteFormattedDocComment()方法中的所有额外内存分配。

例4 StringBuilder

　　本例中使用StringBuilder。下面的函数用来产生泛型类型的全名：

[js] view plaincopy
public class Example   
{   
    // Constructs a name like "SomeType<T1, T2, T3>"   
    public string GenerateFullTypeName(string name, int arity)   
    {   
        StringBuilder sb = new StringBuilder();  
        sb.Append(name);  
        if (arity != 0)  
        {   
            sb.Append("<");  
            for (int i = 1; i < arity; i++)  
            {  
                sb.Append("T"); sb.Append(i.ToString()); sb.Append(", ");  
            }   
            sb.Append("T"); sb.Append(i.ToString()); sb.Append(">");  
        }  
        return sb.ToString();   
    }  
}  

　　注意力集中到StringBuilder实例的创建上来。代码中调用sb.ToString()会导致一次内存分配。在StringBuilder中的内部实现也会导致内部内存分配，但是我们如果想要获取到string类型的结果化，这些分配无法避免。

解决方法：

　　要解决StringBuilder对象的分配就使用缓存。即使缓存一个可能被随时丢弃的单个实例对象也能够显著的提高程序性能。下面是该函数的新的实现。除了下面两行代码，其他代码均相同

[js] view plaincopy
// Constructs a name like "Foo<T1, T2, T3>"   
public string GenerateFullTypeName(string name, int arity)  
{  
    StringBuilder sb = AcquireBuilder(); /* Use sb as before */   
    return GetStringAndReleaseBuilder(sb);  
}  

　　关键部分在于新的 AcquireBuilder()和GetStringAndReleaseBuilder()方法：

[js] view plaincopy
[ThreadStatic]  
private static StringBuilder cachedStringBuilder;  
  
private static StringBuilder AcquireBuilder()  
{  
    StringBuilder result = cachedStringBuilder;  
    if (result == null)  
    {  
        return new StringBuilder();  
    }   
    result.Clear();   
    cachedStringBuilder = null;   
    return result;  
}  
  
private static string GetStringAndReleaseBuilder(StringBuilder sb)  
{  
    string result = sb.ToString();   
    cachedStringBuilder = sb;   
    return result;  
}  

　　上面方法实现中使用了 thread-static字段来缓存StringBuilder对象，这是由于新的编译器使用了多线程的原因。很可能会忘掉这个ThreadStatic声明。Thread-static字符为每个执行这部分的代码的线程保留一个唯一的实例。

　　如果已经有了一个实例，那么AcquireBuilder()方法直接返回该缓存的实例，在清空后，将该字段或者缓存设置为null。否则AcquireBuilder()创建一个新的实例并返回，然后将字段和cache设置为null 。

　　当我们对StringBuilder处理完成之后，调用GetStringAndReleaseBuilder()方法即可获取string结果。然后将StringBuilder保存到字段中或者缓存起来，然后返回结果。这段代码很可能重复执行，从而创建多个StringBuilder对象，虽然很少会发生。代码中仅保存最后被释放的那个StringBuilder对象来留作后用。新的编译器中，这种简单的的缓存策略极大地减少了不必要的内存分配。.NET Framework 和 MSBuild中的部分模块也使用了类似的技术来提升性能。

　　简单的缓存策略必须遵循良好的缓存设计，因为他有大小的限制cap。使用缓存可能比之前有更多的代码，也需要更多的维护工作。我们只有在发现这是个问题之后才应该采缓存策略。PerfView已经显示出StringBuilder对内存的分配贡献相当大。

123 4 / 4 页下一页在本页阅读全文