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

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

Я создал консольное приложение, перестроил его в режиме выпуска (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% - все еще много. Кажется, есть ошибка в 64-битном JIT-компиляторе .NET4.

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

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

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

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

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

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

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

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

ой, только на 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);
    }
}

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

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

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

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

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