Berechnungen nach dem Kaltstart zu langsam

Hallo,

wir haben bei unserer Applikation ein Problem dass mit dem Kaltstart (also PC-Neustart) zu tun hat.

Bei unserer Applikation (C# 4.0.3, VS2010) finden komplexe Berechnungen statt, diese müssen so schnell wie möglich erledigt sein (im Mittelwert darf die Berechnungszeit die 180ms nicht übersteigen).

Wenn ich nun unser Programm immer manuell neustarte habe ich keine Probleme, auch nicht beim ersten Aufruf der Berechnung. Diese ist zwar geringfügig länger, ist aber noch im grünem Bereich (max. 120ms).

Wenn ich nun den PC komplett neustarte, dann ist es sehr oft so dass die Zeit nicht mehr ausreicht. Die Berechnungszeit liegt dann bei maximum 308ms.

Wenn man die erste Berechnung außen vor lässt, liegt die normale Berechnungszeit bei ~90ms.

Während der Initialisierung wird bereits jede mögliche Instanz der vorhanden Plugins erstellt damit .Net die Bibliotheken nachladen kann um hier die Zeit zu minimieren. Desweiteren wird dabei auch eine Pseudo-Berechnung ausgeführt um hier ebenfalls die Bibliotheken nachzuladen, dies hat schon eine deutliche Verbesserung gebracht, nur leider immer noch nicht ausreichend (vorher waren wir bei 600-1500ms).

Ich habe bereich mit NGEN getestet und es hat uns keine Besserung gebracht.

Hat jemand eine Idee was man noch probieren könnte?

Danke im Voraus
Steffen

Nach welcher Zeit nach dem Neustart "normalisiert" sich die Berechnungszeit? (Dauert seine Zeit bis alle Services usw gestartet sind)

Wie lange wartest du nach dem Neustart/Start der Anwendung bis die Berechnung startet?

Hallo steffen_dec,

hast du die in App langsam nach erstem Start, schnell nach allen anderen. erwähnten bzw. verlinkten Möglichkeiten schon probiert?

Möglich wäre auch den Berechnungs-Kern in eine eigene Assembly auszulagern, sofern das ohnehin nicht schon geschehen ist, und mit einem Windows-Service, der mit Windows gestartet wird, im OnStart gleich eine Dummy-Berechnung anzustossen, so dass beim Programmstart quasi ein Warmstart (für den Berechnungskern) vorliegt. In Verbindung mit NGen sollten sich so die Probleme lösen lassen.

mfG Gü

Hallo,

die erste Berechnung kann willkürlich nach dem Neustart kommen (abhängig von meinem "Bereitsignal"), ich habe schon mal paar Minuten gewartet bis ich einen "Trigger" ausgelöst habe.

Bei der zweiten Berechnung ist es dann immer gleich viel schneller. Es ist immer nur die erste Auswertung nach dem Kaltstart die Probleme verursacht. Es geht mir hier nicht um die Dauer des Startvorgangs (dieses ist nicht relevant und darf quasi beliebig lang gehen da der Master auf ein Signal von uns wartet). Während dem Startvorgang mache ich bereits eine Pseudo-Auswertung um so die Berechnungszeit für die echte erste Berechnung zu minimieren, dies ist jetzt schon viel besser geworden, aber eben noch nicht ausreichend.

@gfoidl:
Den Thread habe ich auch schon vorher durchgelesen und die Links auch teilweise, aber so wie ich es verstanden habe geht es da in den Links eher um die Dauer des Startvorgangs und nicht die allgemeine Performance!? Die Auslagerung des Kerns ist nicht so einfach möglich, gewisse Teile sind bereits als Plugins ausgelagert und der Kern ist eben noch in der Haupt-Applikation (natürlich auf verschiedene Threads aufgeteilt).

Für weitere Hinweise bin ich sehr dankbar 👍

MfG
Steffen

Hast Du schon mal einen Profiler drauf angesetzt und/oder mehr Messpunkte eingefuegt - je nach Art der Berechnung kann es auch nur rein an der Speicherallokation liegen.

Hallo,

Profiler ist hier etwas schwierig da dieser ja die Performance ebenfalls verschlechtert...
Man kann aber natürlich die erste Berechnung mit der zweiten Vergleichen, dies werde ich mal angehen.

Kann es sein dass mir da Windows einen Streich spielt indem die Threads beispielsweise einem anderem Kern zugeordnet werden und während dessen der Trigger für die Berechnung kommt?

Als CPU wird hier ein Xeon E5-2660 mit Win7 x64 und 16GB Ram eingesetzt.

Ich vermute, dass sich das Verhalten aufgrund des JIT-Verhaltens nicht so einfach lösen lässt.
Der JIT-Kompiler erkennt HotSpots relativ schnell und genau - und diese werden eben beim ersten Durchlauf erst analysiert und gemerk (native image creation). Eine erste Berechnung hilft in den meisten Fällen; jedoch werden bestimmte Teile erst ins Image geschrieben, wenn ein Programmteil mehrfach durchlaufen wurde.

Da Du von Berechnungen sprichst und gerade algorithmische Ausführungen in Zusammenhang mit LINQ und Math für HotSpots sorgen, könnte meine These stimmen.

Es wäre auch interessant zu wissen, von welcher Art Applikation Du redest.
Ist es eine .NET Desktop-Anwendung oder irgendeine Web-Anwendung? Bei zweiterem wird Dir nämlich das First Loading bzw. der Pre-Compiler einen Strich durch die Rechnung machen.
Dies gilt für alle Anwendungen, die mit einem IIS Webserver betrieben werden.
Es gibt dafür ein compilation Attribut bzw. ein compilation batch attribut, das man auf false stellen muss. Dann dauer der Kompilier-Prozess länger aber die Pre-Compilation wird quasi vorgezogen.

Es handelt sich um eine Desktop-Anwendung, genauer gesagt werden hier Bilder von GigE-Kameras ausgewertet (Bildverarbeitung). Wobei die reine Auswertung in einer Bibliothek (unmanaged mit .Net-Wrapper) von Dritthersteller stattfindet.

Die Berechnungszeit beim ersten Bild geht aber auch nicht rein für die Bildauswertung der BV-Bibliothek sondern auch an dass drumherum.

Nun muss ich schauen dass ich diese Zeit drumherum so gering wie möglich halte, auch nach einem Kaltstart.

Five Great .NET Framework 4.5 Features: Feature 4: Profile optimization (Improved startup performance)

Vielleicht hilft das ja etwas.

Dass Du natürlich mit unmanaged Elementen arbeitest ist ein Hindernis, die beim Laden deutlich länger brauchen als managed Elemente - oft doppelt so lang wie managed Zugriffe.
Es wird ein Overhead produziert, der bei solchen Dingen nicht unterschätzt werden darf. Daher sind .NET Klassen, die sich um die Managed-Unmanages-Kommunikation kümmern auch so dermaßen optimiert wie kaum ein anderer Teil im Framework - insbesondere der Marshaller.

Vielleicht mal hier ein wenig forschen.