Разница между локальной переменной и переменной, вызываемой из метода? C # - PullRequest
1 голос
/ 20 мая 2009

Я хотел бы знать, что быстрее. Помоги мне.

У меня есть переменная, объявленная в методе примерно так:

    public static Regex FindNumber()
{ return new Regex(@"\d+", RegexOptions.IgnoreCase | RegexOptions.Compiled); }

Как видите, он возвращает регулярное выражение.

У меня также есть другой метод, который выглядит так:

    private static string TestOne(string RawData)
{
    Regex rgxFindNumber = FindNumber();
    Regex rgxFindDays = FindDays();
    for (int i = 0; i < mc.Count; i++)
    {
        int days = Convert.ToInt32(rgxFindNumber.Match(rgxFindDays.Match(mc[i].Value).Value).Value);
    }
    return RawData;
}

Теперь метод TestOne будет быстрее или TestTwo?

        private static string TestTwo(string RawData)
{
    for (int i = 0; i < mc.Count; i++)
    {
        int days = Convert.ToInt32(FindNumber().Match( FindDays().Match(mc[i].Value).Value).Value);
    }
    return RawData;
}

Теперь мне любопытно, потому что TestOne можно назвать ужасной партией в моем коде, поэтому я хотел бы знать, что лучше реализовать.

Спасибо, ребята.

** Редактировать: ** Код, который я использую, имеет очень большой класс. Это анализатор текста для текстовой стратегии игры. Я пытаюсь немного изменить его, и это то, что мне интересно здесь. Если я создам приватную переменную для Regex, не будет ли она выполняться каждый раз, когда к классу обращаются? Вот мой вопрос к тебе.

Ответы [ 3 ]

4 голосов
/ 20 мая 2009

TestOne будет быстрее, чем TestTwo, потому что вы не создаете новое регулярное выражение для каждой итерации цикла.

Это имеет два преимущества:

  • Время, используемое для разбора и построения объектов для регулярного выражения, выполняется только один раз вместо mc.Count раз
  • Меньше нагрузки на сборку мусора, поскольку построено меньше объектов.

Однако я бы пошел еще дальше. Если вы всегда собираетесь возвращать одно и то же регулярное выражение и беспокоитесь о скорости, я бы кэшировал этот объект регулярного выражения в статическом поле.

Например, вы могли бы рассмотреть это:

private static Regex _FindNumber;
public static Regex FindNumber()
{
    if (_FindNumber == null)
        _FindNumber = new Regex(@"\d+", RegexOptions.IgnoreCase | RegexOptions.Compiled);
    return _FindNumber;
}

Это создаст всего один объект, всего и сохранит его.

Однако, и вот мой реальный ответ.

Чтобы на самом деле узнать, какой из них будет самым быстрым, вам придется измерить ваш код, возможно, с моим вариантом, добавленным для хорошей меры, и затем принять решение. Никогда не выбирайте оптимизацию без твердых данных, вы можете потратить время на переписывание кода, что может привести к появлению новых ошибок, которые потребуют исправления, на которое вы будете тратить больше времени, только чтобы получить еще 1% производительности.

Большие оптимизации выполняются алгоритмически, как изменение типа алгоритма сортировки, и только затем, если необходимо, вы переходите к локальным оптимизациям, таким как настройка цикла.

Сказав это, я бы по крайней мере избежал создания объекта в цикле, это просто здравый смысл.

1 голос
/ 20 мая 2009

Технически TestOne будет быстрее, потому что TestTwo добавляет кадр стека, вызывая FindNumber ().

Я не знаю, сколько это будет иметь значения, я сомневаюсь, что это так много. Ваш метод статичен, поэтому на самом деле это просто создание объекта, который должен быть довольно быстрым.

Мой вопрос к вам: почему вы используете вызов функции, чтобы возвращать одну и ту же строку снова и снова? Почему бы вам просто не объявить реальную переменную?

Как,

private static Regex _findNumber = new Regex(@"\d+", RegexOptions.IgnoreCase | RegexOptions.Compiled);
1 голос
/ 20 мая 2009

Я полагаю, что TestOne будет быстрее, потому что в TestTwo вы создаете новый объект Regex каждый раз, когда выполняете цикл. Если FindDays реализован так же, как FindNumber, это будет еще хуже, так как вы создадите два объекта.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...