Производительность анализа (If, TryParse, Try-Catch) - PullRequest
31 голосов
/ 29 сентября 2008

Я знаю много о различных способах обработки текста для информации. Например, для анализа целых чисел, какую производительность можно ожидать. Мне интересно, если кто-нибудь знает какие-либо хорошие статистические данные по этому вопросу. Я ищу реальные цифры от кого-то, кто проверял это.

Что из перечисленного обеспечивает наилучшую производительность в каких ситуациях?

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
}

Ответы [ 5 ]

62 голосов
/ 29 сентября 2008

Всегда используйте T.TryParse (строка str, значение T out) . Бросать исключения стоит дорого, и его следует избегать, если вы можете справиться с ситуацией a priori . Использование блока try-catch для «экономии» производительности (поскольку у вас недопустимая скорость передачи данных) является злоупотреблением обработкой исключений за счет удобства обслуживания и хороших методов кодирования. Следуйте обоснованным методам разработки программного обеспечения, напишите свои тестовые примеры, запустите свое приложение, ТОГДА тестируйте и оптимизируйте.

«Мы должны забыть о малой эффективности, скажем, в 97% случаев: преждевременная оптимизация - корень всего зла . Однако мы не должны упускать наши возможности в эти критические 3%» - Дональд Кнут

Поэтому вы произвольно назначаете, как в углеродных кредитах, что производительность try-catch хуже и что производительность TryParse лучше . Только после того, как мы запустили наше приложение и определили, что у нас есть какое-то замедление w.r.t. Разбор строк мы бы даже рассмотрели с использованием чего-либо, кроме TryParse.

(редактировать: поскольку выясняется, что спрашивающий хотел, чтобы данные хронометража давались с хорошим советом, вот запрошенные данные хронометрирования)

Время для различной частоты отказов на 10000 входов от пользователя (для неверующих):

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);
}
8 голосов
/ 29 сентября 2008

Хотя я лично не представлял различные способы, этот глава имеет:

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

6 голосов
/ 29 сентября 2008

Try-Catch всегда будет медленнее. TryParse будет быстрее.

IF и TryParse одинаковы.

2 голосов
/ 28 января 2018

Вот еще еще один глава, который также профилирует различия в производительности и делает это с несколькими различными типами данных, чтобы увидеть, насколько сильно (если вообще) они влияют на производительность: int, bool и DateTime.

0 голосов
/ 29 сентября 2008
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, возможно, это был лучший вариант.)

...