Почему добавление локальных переменных делает код .NET медленнее

Ответ 1

Вопрос должен быть "Почему я вижу такую ​​разницу на моей машине?". Я не могу воспроизвести такую ​​огромную разницу в скорости и подозреваю, что в вашей среде есть что-то конкретное. Очень сложно сказать, что это может быть. Могут быть некоторые (компиляторы) параметры, которые вы установили некоторое время назад и забыли о них.

Я создаю консольное приложение, перестраиваю в режиме Release (x86) и запускаю VS. Результаты практически идентичны, 1,77 секунды для обоих методов. Вот точный код:

static void Main(string[] args)
{
    Stopwatch sw = new Stopwatch();
    sw.Start();
    int count = 0;

    for (uint i = 0; i < 1000000000; ++i)
    {
        // 1st method
        var isMultipleOf16 = i % 16 == 0;
        count += isMultipleOf16 ? 1 : 0;

        // 2nd method
        //count += i % 16 == 0 ? 1 : 0;
    }

    sw.Stop();
    Console.WriteLine(string.Format("Ellapsed {0}, count {1}", sw.Elapsed, count));
    Console.ReadKey();
}

Пожалуйста, у кого есть 5 минут, скопируйте код, перестройте, запустите VS и опубликуйте результаты в комментариях к этому ответу. Я бы хотел не сказать "это работает на моей машине".

ИЗМЕНИТЬ

Чтобы убедиться, что я создал приложение 64-разрядное Winforms, и результаты аналогичны результатам в вопросе. первый метод медленнее (1,57 с), чем второй (1.05 сек). Разница, которую я наблюдаю, составляет 33% - еще много. Кажется, есть ошибка в .NET4 64-битном JIT-компиляторе.

Ответ 2

Я не могу говорить с компилятором .NET или его оптимизацией или даже КОГДА он выполняет свои оптимизации.

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

Это просто пример того, где оптимизация может быть отключена. Могут быть и другие. Оптимизация может произойти во время фазы загрузки кода, а не фазы генерации кода из CLR.

Современные среды выполнения довольно сложны, особенно если вы используете JIT и динамическую оптимизацию во время выполнения. Я чувствую благодарность, что код делает то, что он говорит, иногда.

Ответ 3

Это ошибка в .NET Framework.

Ну, на самом деле я просто размышляю, но я представил отчет об ошибке Microsoft Connect, чтобы узнать, что они говорят. После того, как Microsoft удалила этот отчет, я повторно отправил его в проект roslyn на GitHub.

Обновление: Microsoft перенесла проблему в проект coreclr. Из комментариев по этой проблеме, называя это ошибкой, кажется немного сильным; это скорее недостающая оптимизация.

Ответ 4

Я думаю, что это связано с другим вопросом. Когда я меняю свой код следующим образом, выигрывает многострочная версия.

oops, только на x86. На x64 многострочная линия является самой медленной, и условное выражение их обоих удобно.

class Program
{
    static void Main()
    {
        ConditionalTest();
        SingleLineTest();
        MultiLineTest();
        ConditionalTest();
        SingleLineTest();
        MultiLineTest();
        ConditionalTest();
        SingleLineTest();
        MultiLineTest();
    }

    public static void ConditionalTest()
    {
        Stopwatch stopwatch = new Stopwatch();
        stopwatch.Start();
        int count = 0;
        for (uint i = 0; i < 1000000000; ++i) {
            if (i % 16 == 0) ++count;
        }
        stopwatch.Stop();
        Console.WriteLine("Conditional test --> Count: {0}, Time: {1}", count, stopwatch.ElapsedMilliseconds);
    }

    public static void SingleLineTest()
    {
        Stopwatch stopwatch = new Stopwatch();
        stopwatch.Start();
        int count = 0;
        for (uint i = 0; i < 1000000000; ++i) {
            count += i % 16 == 0 ? 1 : 0;
        }
        stopwatch.Stop();
        Console.WriteLine("Single-line test --> Count: {0}, Time: {1}", count, stopwatch.ElapsedMilliseconds);
    }

    public static void MultiLineTest()
    {
        Stopwatch stopwatch = new Stopwatch();
        stopwatch.Start();
        int count = 0;
        for (uint i = 0; i < 1000000000; ++i) {
            var isMultipleOf16 = i % 16 == 0;
            count += isMultipleOf16 ? 1 : 0;
        }
        stopwatch.Stop();
        Console.WriteLine("Multi-line test  --> Count: {0}, Time: {1}", count, stopwatch.ElapsedMilliseconds);
    }
}

Ответ 5

Я обычно думаю об этом так: люди, которые работают над компилятором, могут делать столько всего в год. Если бы за это время они могли реализовать лямбды или множество классических оптимизаций, я бы проголосовал за лямбда. С# - это язык, который эффективен с точки зрения чтения и записи кода, а не с точки зрения времени выполнения.

Поэтому разумно для команды сосредоточиться на функциях, которые максимизируют эффективность чтения/записи, а не эффективности исполнения в определенном случае с углом (из которых, вероятно, тысячи).

Первоначально, я полагаю, идея заключалась в том, что JITTER выполнит всю оптимизацию. К сожалению, JITting занимает заметное количество времени, и любая передовая оптимизация сделает его еще хуже. Так что это не сработало, как можно было надеяться.

Одна вещь, которую я нашел о программировании действительно быстрого кода на С#, заключается в том, что довольно часто вы сталкиваетесь с серьезным узким местом GC до того, как любая оптимизация, как вы упомянули, изменит ситуацию. Например, если вы выделяете миллионы объектов. С# оставляет вам очень мало шансов избежать затрат: вместо этого вы можете использовать массивы структур, но полученный код действительно уродлив в сравнении. Моя точка зрения заключается в том, что многие другие решения о С# и .NET делают такие конкретные оптимизации менее полезными, чем они были бы в компиляторе С++. Heck, они даже снизили оптимизацию для конкретного процессора в NGEN, эффективность торговли для эффективности программы (отладчика).

Сказав все это, мне бы понравился С#, который фактически использовал оптимизации, которые С++ использовал с 1990-х годов. Только не за счет таких функций, как, скажем, async/await.