Тривала компіляція Visual Studio при заміні int на double

Моя копія VS2013 Ultimate компілює цей код протягом 60+ секунд:

class Program
{
    static void Main(string[] args)
    {
        double dichotomy = Dichotomy(
            d =>
            {
                try
                {
                    int size = (int) d;
                    byte[] b = new byte[size];
                    return -b.Length;
                }
                catch (Exception)
                {
                    return 0;
                }
            },
            0,
            int.MaxValue,
            1);

        Console.WriteLine(dichotomy);
        Console.ReadKey();
    }

    private static double Dichotomy(
        Func<double, double> func,
        double a,
        double b,
        double epsilon)
    {
        double delta = epsilon / 10;
        while (b - a >= epsilon)
        {
            double middle = (a + b) / 2;
            double lambda = middle - delta, mu = middle + delta;
            if (func(lambda) < func(mu))
                b = mu;
            else
                a = lambda;
        }
        return (a + b) / 2;
    }
}

Але якщо я заміню doubleна int, він компілюється негайно. Як це можна пояснити ...?

Я повторюю, 27 секунд на моїй машині. Злочинцем є MsMpEng.exe, він так довго спалює ядро ​​100%. Це легко побачити на вкладці Процеси диспетчера завдань.

Це служба Windows Defender, яка фактично виконує сканування шкідливих програм. Якщо вимкнути його, знявши позначку з пункту "Увімкнути захист у реальному часі", миттєво виправляється затримка. Так само, як і додавання шляху, де я зберігаю проекти, до вікна "Виключені розташування файлів", ймовірно, ваш улюблений підхід.

Не хотілося б здогадуватися про основну причину, але припустити, що ваш вихідний код запускає правило зловмисного програмного забезпечення. Не чудове пояснення, я не бачу затримки, коли я націлююсь на .NET версію <4.0. Гаразд, я здаюся :)

Я не можу сказати авторитетно, тому що минуло 20+ років з того часу, як я возився на рівні коду збірки, але я легко можу повірити в це.

Різниця між стандартними операційними системами IEEE з плаваючою комою та реалізованими процесором часто змушує здійснювати переклади в бібліотечних підпрограмах, тоді як цілочисельна математика може просто використовувати інструкції центрального процесора. На той час, коли IEEE визначив стандарт, вони зробили деякі варіанти, які були дуже рідкісними при реалізації, і особливо, що давно набагато дорожче впроваджувати в мікрокоді, і, звичайно, нинішні системи ПК побудовані навколо чіпів, що походять з 80387 та 80486 , які передують стандарту.

Отже, якщо я маю рацію, збільшений час пов’язаний з тим, що він передбачає додавання фрагмента бібліотечного коду до посилання, а зв’язування - це велика частина часу збірки, яка має тенденцію до мультипликативного зростання при додаванні переміщуваних шматків.

Clang на Linux може або не матиме такого ж уповільнення; якщо це вдасться уникнути і ще більше розширити мої здогади, це буде артефактом всюдисущої спільної пам'яті libc, яку ви там отримаєте, та оптимізацією компонентів навколо цього.