Защо добавянето на локални променливи прави .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% - пак много. Изглежда, че има грешка в .NET4 64-битов JIT компилатор.

Не мога да говоря с .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++ компилатор. По дяволите, те дори премахнаха специфичните за CPU оптимизации в NGEN, производителност на търгуване за ефективност на програмист (дебъгер).

Като казах всичко това, бих харесвал C#, който действително използва оптимизации, които C++ използва от 90-те години на миналия век. Просто не за сметка на функции като, да речем, async/await.