Visual Studio lange Kompilierung beim Ersetzen von int durch double

Meine Kopie von VS2013 Ultimate kompiliert diesen Code für mehr als 60 Sekunden:

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;
    }
}

Aber wenn ich ersetzen doublemit intkompiliert es sofort. Wie kann es erklärt werden ...?

— Alex Zhukovskiy
quelle

Kompiliert sofort auf meinem Computer für beide Datentypen ... Auf welchem Computer kompilieren Sie es?

— Chris Mantle

Kratz meinen ersten Kommentar; Ich sehe das gleiche Verhalten. ~ 15 Sekunden mit doubleund sofort mit int. 3,4-GHz-Maschine.

— Kevin Richardson

Interessant. Ich habe meine Version überprüft und verwende derzeit VS2013 Premium - dachte, ich hätte Ultimate installiert. Vielleicht ist es nur die ultimative Version, mit der dies auftritt.

— Chris Mantle

@chris Um diese Hypothese zu unterstützen, kompiliert VS Express 2013 / Windows Desktop sie einwandfrei.

— ClickRick

Nach allem, was ich gehört habe, ist "VS2013 sehr seltsames Verhalten" kaum eine Seltsamkeit. :)

— Leichtigkeitsrennen im Orbit

Antworten:

140

Ich repro, 27 Sekunden auf meiner Maschine. Der Übeltäter ist MsMpEng.exe, es brennt so lange 100% Kern. Einfach auf der Registerkarte Prozesse des Task-Managers zu sehen.

Dies ist der Windows Defender-Dienst, der die Malware-Scans tatsächlich ausführt. Durch Deaktivieren durch Deaktivieren der Option "Echtzeitschutz aktivieren" wird die Verzögerung sofort behoben. Das Hinzufügen des Pfads, in dem ich Projekte speichere, zum Feld "Ausgeschlossene Dateispeicherorte", wahrscheinlich Ihr bevorzugter Ansatz.

Ich würde es hassen, den zugrunde liegenden Grund erraten zu müssen, aber ich muss davon ausgehen, dass Ihr Quellcode eine Malware-Regel auslöst. Keine gute Erklärung, ich sehe keine Verzögerung, wenn ich auf eine .NET-Version <4.0 abziele. Okay, ich gebe auf :)

— Hans Passant
quelle

Omg, Microsoft, du machst Witze ... Tnx um Hilfe, es ist wirklich MSSEund .Net 4.0+wer die Schuldigen sind

— Alex Zhukovskiy

Guter Fang! Ich frage mich, was genau das Problem verursacht (insbesondere für ein Programm, das so einfach ist und fast keine externen Abhängigkeiten enthält). Wäre es möglich, dass das Ergebnis der MSIL-Bytes aus der Kompilierung genau wie ein Muster einer bekannten Malware aussieht und somit MsMpEnd ausgelöst wird?

— Tigrou

-1

Ich kann es nicht verbindlich sagen, weil es mehr als 20 Jahre her ist, seit ich auf der Ebene des Assembler-Codes herumgespielt habe, aber ich kann das leicht glauben.

Der Unterschied zwischen Gleitkommaoperationen nach IEEE-Standard und denen, die von einem Prozessor implementiert werden, erzwingt häufig die Verknüpfung in Bibliotheksroutinen, um die Übersetzung durchzuführen, während die Ganzzahlmathematik nur die CPU-Anweisungen verwenden kann. Zu der Zeit, als das IEEE den Standard definierte, trafen sie einige Entscheidungen, die bei der Implementierung sehr ungewöhnlich waren und insbesondere vor langer Zeit viel teurer in der Implementierung in Mikrocode waren, und natürlich basieren die aktuellen PC-Systeme auf Chips, die von 80387 und 80486 abstammen , die vor dem Standard liegen.

Wenn ich recht habe, ist die längere Zeit darauf zurückzuführen, dass dem Link ein Teil des Bibliothekscodes hinzugefügt wird, und die Verknüpfung ist ein großer Teil der Erstellungszeit, die tendenziell multipliziert wird, wenn verschiebbare Teile hinzugefügt werden.

Clang unter Linux kann die gleiche Verlangsamung haben oder auch nicht. Wenn es dies vermeidet und meine Vermutungen noch weiter ausdehnt, wäre dies ein Artefakt der allgegenwärtigen Shared-Memory-Bibliothek, die Sie dort erhalten, und der dazugehörigen Linker-Optimierungen.

— Weregamer
quelle