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

时间:2020-03-06 14:53:26  来源:igfitidea点击:

我对处理信息解析文本的不同方法了解很多。例如,对于解析整数,可以期待什么样的性能。我想知道是否有人对此有任何好的统计。我正在从测试过的人那里寻找一些实数。

在哪种情况下,哪一个提供最佳性能?

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
}

解决方案

始终使用T.TryParse(string str,out T value)。抛出异常的代价很高,如果可以先验地处理异常,则应避免抛出异常。使用try-catch块"保存"性能(因为无效数据率很低)会滥用异常处理,但会牺牲可维护性和良好的编码习惯。遵循良好的软件工程开发实践,编写测试案例,运行应用程序,然后进行基准测试并进行优化。

"We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%" -Donald Knuth

因此,像碳信用额度一样,我们任意分配try-catch的性能较差,而TryParse的性能则较优。只有在运行我们的应用程序并确定我们的运行速度有所降低之后,字符串解析甚至可以考虑使用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);
}

Try-Catch总是比较慢。 TryParse将更快。

IF和TryParse相同。

尽管我还没有亲自介绍过不同的方式,但本章介绍了以下内容:

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

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之前,它可能是最好的选择。)