Wo ist die .NET JIT-kompilierten code-Cache?

Ein .NET-Programm wird zunächst compiliert in MSIL-code. Wenn es ausgeführt wird, wird der JIT-compiler kompilieren in nativen Maschinen-code.

Frage ich mich:

Wo ist diese JIT-kompilierte Maschinencode gespeichert? Ist es nur gespeichert im Adressraum des Prozesses? Aber seit dem zweiten Start des Programms ist viel schneller als beim ersten mal, ich denke, das native-code muss schon auf der Festplatte gespeichert, irgendwo auch nach der Ausführung beendet hat. Aber wo?

InformationsquelleAutor smwikipedia | 2010-07-21
  1. 73

    Speicher. Es kann zwischengespeichert werden, das ist die Aufgabe von ngen.exe. Es generiert einen .ni.dll -version der assembly, mit Maschine code und im GAC gespeichert. Die automatisch geladen wird danach, unter Umgehung der JIT-Schritt.

    Aber das hat wenig zu tun mit, warum Sie Ihr Programm schneller startet, das 2. mal. Das 1. mal, Sie haben einen sogenannten "Kaltstart". Das ist völlig dominiert von der verbrachten Zeit auf der Suche nach den DLLs auf der Festplatte. Das zweite mal haben Sie einen warm-start, die DLLs sind, die bereits in den Dateisystem-cache.

    Festplatten sind langsam. Eine SSD ist ein offensichtlicher fix.

    Fwiw: das ist kein problem, die exklusiv in verwaltetem code. Große unmanaged-Programme mit vielen DLLs haben es auch. Zwei kanonische Beispiele, vorhanden auf den meisten dev-Maschinen sind Microsoft Office und Acrobat Reader. Sie betrügen. Wenn installiert, Sie setzen ein "optimizer" in der Run-registry-Schlüssel oder Autostart-Ordner. Alle, die diese Optimierer tun ist, laden Sie alle DLLs, die das Hauptprogramm benutzt, dann exit. Diese Primzahlen die Datei-system-cache, wenn der Benutzer nachfolgend wird das Programm, startet es schnell, da seine warm-start ist schnell.

    Persönlich, ich finde das außerordentlich ärgerlich. Denn das, was Sie wirklich tun ist, zu verlangsamen, alle anderen Programme, die ich vielleicht möchten Sie nach der Anmeldung. Das ist selten Office oder Acrobat. Ich mache es einen Punkt zu löschen, diese Optimierer, wiederholt, wenn notwendig, wenn ein gesprengter update bringt ihn zurück.

    Können Sie mit diesem trick auch, aber benutzen Sie bitte verantwortungsvoll.

    • Vista und Windows 7 haben diese DLL-caching trick eingebaut, so dass Sie nicht brauchen, um stellen Sie "app-Beschleuniger" nicht mehr. Superfetch Datensätze, welche Anwendungen Sie am meisten verwenden, und Lesen Sie die Dateien nach dem Booten. Es ist besser, als eine Beschleuniger-app, weil es achtet auf den aktuellen Speicherverbrauch und die aktuelle Anwendung verwenden.
    • Sie erzählte "It generates a .ni.dll version of the assembly, containing machine code and stored in the GAC" . Ich habe einige Zweifel.. GAC ist nur für die Speicherung von öffentlichen Versammlungen, richtig ? Es speichert eine Native Image einer exe dass ich laufen ?
    • Ja, das ist es, was die Antwort sagt. Es ist aus dem Blick verborgen, aber man sieht es durch starten der Eingabeaufforderung. Geben Sie dir c:\windows\assembly um die Liste der Verzeichnisse in den GAC.
    InformationsquelleAutor Hans Passant
  2. 11

    Wie andere haben darauf hingewiesen, code JIT würde pro Prozess in Ihrem Fall und nicht zwischengespeichert - die speed-up-Sie sehen auf dem zweiten load OS disk-caching (also im Speicher) der Baugruppen.

    Jedoch, während es ist keine Zwischenspeicherung (abgesehen von OS disk-caching) in der desktop\server version des Frameworks, es ist das caching von JIT würd Maschine code in einer anderen version des Frameworks.

    Des Interesses ist das, was in der .Net Compact Framework (NETCF für Windows Phone 7-relase). Jüngste Fortschritte sehen, die Freigabe von einigen JIT würd framework-code zwischen Prozessen, bei denen die JIT-würde code ist in der Tat zwischengespeichert. Dies wurde in Erster Linie durchgeführt, um eine bessere performance (load-time-und memory-Nutzung) im eingeschränkten Geräten wie Handys.

    So, in Antwort auf die Frage gibt es keine direkte framework-caching von JIT-würde-code in der desktop\server-version der CLR, aber es wird in die neueste version des compact framework, d.h. NETCF.

    Referenz: Wir Glauben an das Teilen

    http://blogs.msdn.com/b/abhinaba/archive/2010/04/28/we-believe-in-sharing.aspx

    InformationsquelleAutor Tim Lloyd
  3. 7

    JIT-kompilierte Maschinencode zwischengespeichert pro-Methode, jedes mal, wenn eine Methode ausgeführt wird, für die erste Zeit. Ich glaube nicht, dass es jemals auf der Festplatte zwischengespeichert.

    Finden Sie möglicherweise, dass der Prozess schneller zu laden, das zweite mal, weil Windows-Cache (in-memory) Sie die Dateien, die von Ihrem Prozess (dlls, Ressourcen etc etc) auf den ersten Lauf. Auf dem zweiten Lauf gibt es keine Notwendigkeit zu gehen auf der Festplatte, kann dies auf den ersten Lauf.

    Könnten Sie dies bestätigen, indem Sie läuft NGen.exe tatsächlich vor-kompilieren Maschinencode für die Architektur, und vergleichen Sie die Leistung von dem ersten und dem zweiten ausgeführt wird. Meine Wette ist, dass der zweite Lauf würde noch schneller sein, aufgrund von caching in OS.

    • Weißt du, wo windows ist das Zwischenspeichern dieser Dateien durch den Prozess (dlls, Ressourcen etc etc) ?
    • Im RAM, das gleiche wie fast jedes andere OS in diesen Tagen.
    InformationsquelleAutor Sam
  4. 2

    Kurz gesagt, der IL ist die JIT-Kompilierung mit jedem Aufruf des Programms beibehalten und ist in den code-Seiten von der Prozess-Adressbereich. Siehe Kapitel 1 Richter für die tolle Berichterstattung von der .NET Ausführung-Modell.

    InformationsquelleAutor lesscode
  5. 1

    Ich glaube, dass der JIT-kompilierte code wird nie gespeichert oder ausgetauscht wird, aus dem Speicher. Die Leistungssteigerung, die Sie wahrnehmen, auf eine zweite Ausführung einer Baugruppe ist aufgrund abhängiger Assemblys bereits im Speicher oder Disk-cache.

    • Nur der kernel-Treiber kann verhindern, dass code wird ausgelagert. JIT-kompilierten code können ausgelagert werden, genauso wie jede andere Seite in der Anwendung in den Speicher.
    InformationsquelleAutor Philip Smith
  6. 1

    Ja, NGEN.EXE eine JIT-kompilierte version der .NET ausführbare Datei, die im GAC, auch wenn
    die MSIL-version gibt es nicht. Ich habe das ausprobiert, aber ohne Erfolg.
    Ich glaube, es sei denn, der ursprüngliche MSIL-version ist auch in der GAC und würde geladen werden
    von dort aus, die JIT-version im GAC nicht verwendet werden.
    Ich glaube auch, dass on-the-fly JIT-kompiliert (nicht NGEN) niemals zwischengespeichert; Sie besetzen Prozess
    Speicher nur.

    Ich glaube, dass dies vom Lesen der MS-doc und von verschiedenen Experimenten. Ich würde es begrüßen, entweder
    eine Bestätigung oder Widerlegung meiner Behauptungen von "wer weiß".

    InformationsquelleAutor Arra Avakian
Schreibe einen Kommentar