不久前，Jon Skeet 的一篇文章在我脑海中植入了构建一个 CompiledFormatter 类的想法，用于在循环中使用而不是 String.Format()。

这个想法是对 String.Format() 的调用部分花在解析格式字符串上的开销；我们应该能够通过将该代码移出循环来提高性能。当然，诀窍是新代码应该完全匹配String.Format() 行为。

这周我终于做到了。我经历了使用 .Net framework source provided by Microsoft直接调整他们的解析器(事实证明 String.Format() 实际上将工作交给了 StringBuilder.AppendFormat())。我想出的代码有效，因为我的结果在我的(公认有限的)测试数据中是准确的。

不幸的是，我还有一个问题:性能。在我的初始测试中，我的代码的性能与普通 String.Format() 的性能非常接近。一点改善都没有；它甚至总是慢几毫秒。至少它仍然处于相同的顺序(即:较慢的数量不会增加；即使测试集增长，它也会保持在几毫秒内)，但我希望有更好的东西。

可能是对 StringBuilder.Append() 的内部调用才是真正插入性能的因素，但我想看看这里的聪明人是否可以帮助改进。

相关部分如下:

private class FormatItem
{
    public int index; //index of item in the argument list. -1 means it's a literal from the original format string
    public char[] value; //literal data from original format string
    public string format; //simple format to use with supplied argument (ie: {0:X} for Hex

    // for fixed-width format (examples below) 
    public int width;    // {0,7} means it should be at least 7 characters   
    public bool justify; // {0,-7} would use opposite alignment
}

//this data is all populated by the constructor
private List<FormatItem> parts = new List<FormatItem>(); 
private int baseSize = 0;
private string format;
private IFormatProvider formatProvider = null;
private ICustomFormatter customFormatter = null;

// the code in here very closely matches the code in the String.Format/StringBuilder.AppendFormat methods.  
// Could it be faster?
public String Format(params Object[] args)
{
    if (format == null || args == null)
        throw new ArgumentNullException((format == null) ? "format" : "args");

    var sb = new StringBuilder(baseSize);
    foreach (FormatItem fi in parts)
    {
        if (fi.index < 0)
            sb.Append(fi.value);
        else
        {
            //if (fi.index >= args.Length) throw new FormatException(Environment.GetResourceString("Format_IndexOutOfRange"));
            if (fi.index >= args.Length) throw new FormatException("Format_IndexOutOfRange");

            object arg = args[fi.index];
            string s = null;
            if (customFormatter != null)
            {
                s = customFormatter.Format(fi.format, arg, formatProvider);
            }

            if (s == null)
            {
                if (arg is IFormattable)
                {
                    s = ((IFormattable)arg).ToString(fi.format, formatProvider);
                }
                else if (arg != null)
                {
                    s = arg.ToString();
                }
            }

            if (s == null) s = String.Empty;
            int pad = fi.width - s.Length;
            if (!fi.justify && pad > 0) sb.Append(' ', pad);
            sb.Append(s);
            if (fi.justify && pad > 0) sb.Append(' ', pad);
        }
    }
    return sb.ToString();
}

//alternate implementation (for comparative testing)
// my own test call String.Format() separately: I don't use this.  But it's useful to see
// how my format method fits.
public string OriginalFormat(params Object[] args)
{
    return String.Format(formatProvider, format, args);
}

我对提供我的构造函数的源代码持谨慎态度，因为我不确定我对原始 .Net 实现的依赖所带来的许可影响。然而，任何想要对此进行测试的人都可以将相关的私有(private)数据公开并分配模仿特定格式字符串的值。

此外，如果有人提出可以缩短构建时间的建议，我非常愿意更改 FormatInfo 类，甚至更改 parts List。由于我主要关心的是从前端到端的顺序迭代时间，也许 LinkedList 会更好？

[更新]:

嗯...我可以尝试的其他事情是调整我的测试。我的基准测试相当简单:将姓名组成 "{lastname}, {firstname}" 格式，并根据区号、前缀、号码和分机号组成格式化的电话号码。这些都没有太多影响字符串中的文字段。当我思考原始状态机解析器的工作方式时，我认为这些文字段正是我的代码最有可能做好的地方，因为我不再需要检查字符串中的每个字符。

这门课仍然有用，即使我不能让它走得更快。只要性能不比基本 String.Format() 差，我仍然创建了一个强类型接口(interface)，它允许程序在运行时组装它自己的“格式字符串”。我需要做的就是提供对部件列表的公共(public)访问。

最佳答案

这是最终结果:

我在基准试验中将格式字符串更改为更适合我的代码的内容:

The quick brown {0} jumped over the lazy {1}.

如我所料，这比原来的票价要好得多；此代码在 5.3 秒内进行了 200 万次迭代，而 String.Format 则为 6.1 秒。这是不可否认的改进。您甚至可能想开始使用它作为许多 String.Format 情况下的简单替代品。毕竟，您不会做得更糟，甚至可能会获得小幅性能提升:多达 14%，这没什么好小瞧的。

除此之外。请记住，在专门为支持此代码而设计的情况下，我们仍在谈论 2 百万 次尝试的差异小于半秒。即使是繁忙的 ASP.Net 页面也不太可能产生那么大的负载，除非您有幸在排名前 100 的网站上工作。

最重要的是，这忽略了一个重要的替代方案:您可以每次创建一个新的 StringBuilder 并使用原始 Append() 调用手动处理您自己的格式。使用该技术，我的基准测试在仅 3.9 秒内完成。这是一个更大的改进。

总而言之，如果性能不是那么重要，您应该坚持使用内置选项的清晰和简单。但是，当分析显示这确实在提高性能时，可以通过 StringBuilder.Append() 获得更好的替代方案。

关于c# - 性能问题 : comparing to String. 格式，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/761121/