题 解析性能(If,TryParse,Try-Catch)


我对处理解析文本信息的不同方法了解很多。例如,对于解析整数,可以期望什么样的性能。我想知道是否有人知道这方面的任何好的统计数据。我正在寻找测试过这个的人的真实数字。

在哪些情况下,哪些提供最佳性能?

Parse(...)  // Crash if the case is extremely rare .0001%

If (SomethingIsValid) // Check the value before parsing
    Parse(...)

TryParse(...) // Using TryParse

try
{
    Parse(...)
}
catch
{
    // Catch any thrown exceptions
}

31
2017-09-29 18:53


起源


不久前Jon Skeet为这些东西做了一些基准测试。对不起,我没有现成的链接 - 也许打谷歌? - Michael Burr


答案:


一直用 T.TryParse(string str,out T value)。抛出异常是昂贵的,如果你能处理这种情况应该避免 先验。使用try-catch块来“保存”性能(因为您的无效数据速率很低)是滥用异常处理,但代价是可维护性和良好的编码实践。遵循良好的软件工程开发实践,编写测试用例,运行应用程序,然后进行基准测试和优化。

“我们应该忘记效率低,大约97%的时间说: 过早优化是万恶之源。然而,我们不应该在那个关键的3%“-Donald Knuth”中放弃我们的机会

因此,您可以像碳信用额一样任意分配try-catch的性能 更差 并且TryParse的性能是 更好。只有在我们运行我们的应用程序并确定我们有某种减速w.r.t.字符串解析我们甚至会考虑使用除TryParse以外的任何东西。

(编辑:因为看起来提问者希望时间数据有良好的建议,这里是要求的时间数据)

来自用户的10,000个输入(针对非信徒)的各种失败率的时间:

Failure Rate      Try-Catch          TryParse        Slowdown
  0%           00:00:00.0131758   00:00:00.0120421      0.1
 10%           00:00:00.1540251   00:00:00.0087699     16.6
 20%           00:00:00.2833266   00:00:00.0105229     25.9
 30%           00:00:00.4462866   00:00:00.0091487     47.8
 40%           00:00:00.6951060   00:00:00.0108980     62.8
 50%           00:00:00.7567745   00:00:00.0087065     85.9
 60%           00:00:00.7090449   00:00:00.0083365     84.1
 70%           00:00:00.8179365   00:00:00.0088809     91.1
 80%           00:00:00.9468898   00:00:00.0088562    105.9
 90%           00:00:01.0411393   00:00:00.0081040    127.5
100%           00:00:01.1488157   00:00:00.0078877    144.6


/// <param name="errorRate">Rate of errors in user input</param>
/// <returns>Total time taken</returns>
public static TimeSpan TimeTryCatch(double errorRate, int seed, int count)
{
    Stopwatch stopwatch = new Stopwatch();
    Random random = new Random(seed);
    string bad_prefix = @"X";

    stopwatch.Start();
    for(int ii = 0; ii < count; ++ii)
    {
        string input = random.Next().ToString();
        if (random.NextDouble() < errorRate)
        {
           input = bad_prefix + input;
        }

        int value = 0;
        try
        {
            value = Int32.Parse(input);
        }
        catch(FormatException)
        {
            value = -1; // we would do something here with a logger perhaps
        }
    }
    stopwatch.Stop();

    return stopwatch.Elapsed;
}

/// <param name="errorRate">Rate of errors in user input</param>
/// <returns>Total time taken</returns>
public static TimeSpan TimeTryParse(double errorRate, int seed, int count)
{
    Stopwatch stopwatch = new Stopwatch();
    Random random = new Random(seed);
    string bad_prefix = @"X";

    stopwatch.Start();
    for(int ii = 0; ii < count; ++ii)
    {
        string input = random.Next().ToString();
        if (random.NextDouble() < errorRate)
        {
           input = bad_prefix + input;
        }

        int value = 0;
        if (!Int32.TryParse(input, out value))
        {
            value = -1; // we would do something here with a logger perhaps
        }
    }
    stopwatch.Stop();

    return stopwatch.Elapsed;
}

public static void TimeStringParse()
{
    double errorRate = 0.1; // 10% of the time our users mess up
    int count = 10000; // 10000 entries by a user

    TimeSpan trycatch = TimeTryCatch(errorRate, 1, count);
    TimeSpan tryparse = TimeTryParse(errorRate, 1, count);

    Console.WriteLine("trycatch: {0}", trycatch);
    Console.WriteLine("tryparse: {0}", tryparse);
}

61
2017-09-29 18:56



亚里士多德从来没有通过实验来弄脏手。惭愧,羞耻。你需要断言的东西显然是真的。这是互联网的方式! - Chris Cudmore
@chris:我出于某种原因被修改了......我猜真相很痛。 - user7116
感谢你做了一个快速的基准测试,即使try-catch版本是错误的,因此TryParse()更快的事实甚至不需要被证明...... - Michael Burr
@Mike B,无论你认为自己是否知道答案,运行基准和测试都是非常重要的。我刚刚修改了这段代码,以便在0%情况下根本不处理异常。这是我也想要的一个方面,发现它等同于TryParse。 - Brendan Enrick
如果你要使用那个引用,你应该使用完整的引用 - “我们应该忘记效率低,大约97%的时间说:过早的优化是所有邪恶的根源。但我们不应该放弃我们的机会在那个关键的3%“。 - Scott Dorman


虽然我没有亲自描述不同的方式,但这个小伙伴有:

http://blogs.msdn.com/ianhu/archive/2005/12/19/505702.aspx


8
2017-09-29 18:57



好消息。谢谢你指出来。 - Vijesh VP


Try-Catch总是会慢一些。 TryParse会更快。

IF和TryParse是相同的。


6
2017-09-29 18:56



要完全清楚,如果解析失败,Try-Catch只会更慢;不抛出/捕获异常不需要任何费用。 - technophile
是的,我问的部分原因是因为我想知道执行try-catch块的成本与可能什么也不做。 - Brendan Enrick
如果不太可能发生错误,可以期待什么样的性能?这就是为什么我要求这方面的一些统计数据而不只是“这一个更快” - Brendan Enrick
@benrick:它更像是滥用异常框架而不是性能问题。因此,您假设try-catch总是较慢,TryParse总是会更快。 - user7116
@Daok:+1,除非你是未洗过的群众中的一员,否则没有必要的统计数据。 - user7116


这里的 另一个人也描述了性能差异,并使用一些不同的数据类型来查看它们固有地影响性能的程度(如果有的话):int,bool和DateTime。


1
2018-01-28 02:38





Option 1: Will throw an exception on bad data.
Option 2: SomethingIsValid() could be quite expensive - particularly if you are pre-checking a string for Integer parsability.
Option 3: I like this.  You need a null check afterwards, but it's pretty cheap.
Option 4 is definitely the worst.

异常处理相对昂贵,如果可以,请避免使用它。

特别是,不良输入是预期的,而不是例外,所以你不应该在这种情况下使用它们。

(虽然在TryParse之前,它可能是最好的选择。)


-3
2017-09-29 18:59



对于选项1和4:当投掷的可能性可以忽略不计时,OP确实试图确定投掷的成本是否可以忽略不计(他说0.0001%)。选项2和3实际上是一回事。在幕后,TryParse完成了Option 2的功能,假设Option 2没有打开sqlconnections或者奇怪的东西。最后,选项3你永远不必检查null。如果您要添加支票,只需检查尝试的返回。所以,虽然在这一点上你得分很高并且可能知道所有这一切,但我觉得必须加上这个旧答案为什么-2的清晰度。 - Suamere
TryParse的作用: referencesource.microsoft.com/#mscorlib/system/... - Suamere