Wenn eine WPF Anwendung (egal welche) nach einem Windows-Start (egal ob direkt nach dem Start oder eine Stunde später) gestartet wird, dann dauert es länger als 5 Sekunden bis die Anwendung startet. Schießt man die Anwendung und startet die nochmal, ist die sofort da.
Dieses Verhalten kommt wohl davon, dass das .NET Framework bei dem Windows-Start nicht vollständig geladen wird. Bei dem ersten Start einer WPF Anwendung werden dafür benötigte Sachen nachgeladen. Dieses Verhalten kann auf einem beliebigen Windows 7 Rechner beobachtet werden. Bei dem Windows 8.1 Rechner ist das Problem nicht mehr vorhanden.
Kennt jemand eine Möglichkeit das Betriebssystem zu zwingen nach dem Start das .Net Framework automatisch vollständig zu initialisieren? Eine unsichtbare WPF Anwendung im Autostart ist keine Option 😃
Hallo el_vital,
die in Improving WPF applications startup time erwähnten Möglichkeiten / Tipps hast du schon berücksichtigt?
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Hallo gfoidl,
der Artikel hat mit dem Problem nichts zu tun. Eine leere Anwendung ohne Funktion ohne Veränderungen nach Projekterzeugung startet nach einem Windows-Start extrem lange. Das ist ein allgemeines Problem von .Net/WPF unter Windows 7.
Bei Windows Forms gibt es das Problem nicht.
Hallo el_vital,
der Artikel hat mit dem Problem nichts zu tun.
In Bezug auf WPF od. nicht behandeln die Punkte 1, 3, 4, 5, 6, 4, 5, 7, 8, 9, 15 das Problem schon. Die anderen Punkte sind WPF-spezifisch.
Dass es ein generelles Win7/.net-Problem ist kann ich nicht bestätigen. Hast du Vergleiche mit anderen Win-Versionen angestellt? Dabei auch gleiche Einstellungen für SuperFetch u.ä. berücksichtigt?
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Ein anderer Beweis, dass es nicht an der Anwendung selbst liegt:
Es ist egal welche WPF Anwendung zuerst nach Neustart ausgeführt wird. Danach starten alle WPF Anwendungen schnell.
Dass es ein generelles Win7/.net-Problem ist kann ich nicht bestätigen.
Ist auf allen Windows 7 Rechnern mit beliebigen WPF Programmen so.
Kannst du selber schnell testen. Erstell eine neue WPF Anwendung in VS. Kompiliere das Projekt. Starte den Rechner neu. Gib dem Betriebssystem genug Zeit um komplett durchzustarten. Starte jetzt die WPF Anwendung. Der Start wird dauern. Schließ die Anwendung und starte nochmal. Das Programm ist sofort da.
Hallo el_vital,
das glaube ich dir schon, denn soweit ist das übliches Kaltstartverhalten. Nur dass es auf Win 7 bezogen ist glaub ich nicht.
Hast du den verlinkten Artikel überhaupt schon gesehen? Ein paar Punkte daraus gelten sowohl für X als auch Y und alle anderen WPF-Anwendungen.
mfG Gü
Stellt fachliche Fragen bitte im Forum, damit von den Antworten alle profitieren. Daher beantworte ich solche Fragen nicht per PM.
"Alle sagten, das geht nicht! Dann kam einer, der wusste das nicht - und hat's gemacht!"
Es geht doch nicht um Glauben. Auf Windows 8.1 starten WPF Programme nach Windows-Start ohne Verzögerung. Bei Windows 7 und früher bei Windows XP eben nicht. Das hat schon etwas mit dem Betriebssystem zu tun. Bei Windows 8 wird vielleicht ein WPF Programm als Bestandteil des Betriebssystems beim Start ausgeführt. Dadurch starten WPF Programm auch sofort.
Ich suche nach einem Weg unter Windows 7 das .Net Framework bei Windows-Start vollständig zu "laden". Ich habe in einem Forum etwas von einem Registry-Eintrag gelesen. Dort wurde auf Infos auf einer Microsoft-Seite verwiesen. Die Seite ist aber leider nicht mehr erreichbar.
Ist das Problem wirklich noch keinem aufgefallen?
Das Problem ist vermutlich nicht so schlimm wie du es empfindest.
Das Problem kommt eben aus dem Prinzip des Just-in-Time Compilings. Es werden eben nur die Dinge geladen die auch wirklich gebraucht werden deswegen ist ein Konzept wie "das Framework vollständig zu laden" eher unmöglich. Na gut nicht unmöglich ... aber vermutlich nicht sinnvoll.
Wenn dich die (Start-) Performance der Anwendungen derart beeinträchtigt solltest du vielleicht mit dem Gedanken spielen Native Images zu erzeugen.
Hierfür gibt es eben speziell das Tool "ngen"
Ngen.exe (Native Image Generator)
Mit diesen Native Images sollten die Anwendungen etwas performanter laufen (und starten evtl. auch).
Abgesehen dürften WPF Anwendungen gegenüber klassischen .NET Forms Anwendungen auch je nach System nochmal im Vor- oder Nachteil sein. Da hier eben eine andere Art des Grafikrenderings hinzu kommt. (WPF Anwendungen können bei der Grafikdarstellung von entsprechende Grafikhardware gebrauch machen, wenn vorhanden. Aber wenn eben ein schwaches System mit der angeforderten opulenten Darstellung überfordert ist wird WPF sicherlich nicht schneller sein als das grafisch anspruchslose .NET Forms)
Weiter würde ich gerne nachfragen:
Bist du sicher das es am .NET Framework liegt und nicht evtl. an anderen Komponenten wie zum Beispiel dem SQL Server den du aus deiner Anwendung heraus verwendest?
Aus Erfahrung zum Beispiel weiß ich das ein neu gestarteter SQL Server auch erst mal ein bisschen Zeit braucht um warm zu werden.
Weiter würde ich gerne nachfragen:
Bist du sicher das es am .NET Framework liegt und nicht evtl. an anderen Komponenten wie zum Beispiel dem SQL Server den du aus deiner Anwendung heraus verwendest?
Aus Erfahrung zum Beispiel weiß ich das ein neu gestarteter SQL Server auch erst mal ein bisschen Zeit braucht um warm zu werden.
Eine leere WPF Anwendung ohne jegliche DLL's/SQL Nutzung hat ebenfalls dieses Verhalten.
Ngen habe ich bereits ausprobiert, bringt garnichts, da es wirklich um das "laden" des Frameworks bei der ersten Ausführung einer WPF Anwendung geht.
Ich werde schon eine Lösung finden und hier posten.
das Problem von el_vital ist mir auch schon aufgefallen...allerdings ist die Verzögerung nicht so krass wie sie el_vital beschreibt...bei mir dauert es nur länger, wenn ich in visual studio ein wpf projekt compiliere...eine ausführbare datei mit wpf startet kaum verzögert
Ich bezweifle sehr sehr stark, dass das ein generelles Problem von WPF sein oder gar am Betriebssystem liegen soll.
Eine Managed-Application hat immer einen Kaltstart, der nach dem ersten Start bei einem Reboot oder wenn die Anwendung länger nicht gelaufen ist auftritt.
Diesen kann man auch nur verbessern aber nicht verhindern. Der größte Impact beim Kaltstart ist übrigens der I/O.
Da kann die Anwendung noch so leer sein; hat sie viele unnötige Referenzen, eine schlechte HDD oder den falschen HDD-Treiber, dann hat das massiven Einfluss auf den Kaltstart.
Hinzu kommt, dass die Anzeige von WPF auf DirectX angewiesen ist und hier eine fehlerhafte Version bzw. ein Grafikkartentreiber sehr viel Schaden beim Laden und Benutzen ausrichten kann.
Es ist aus dem Beitrag nicht mal ersichtlich, ob wir nur von unterschiedlichen Betriebssystemen oder auch von unterschiedlichen PC-Systemen sprechen.
Das Pauschal-Bashing ist jedenfalls keine Lösung.
Ich suche nach einem Weg unter Windows 7 das .Net Framework bei Windows-Start vollständig zu "laden".
Zeigt mir eher, dass Du nicht verstehst, wie .NET funktioniert.
Du kannst nicht das ganze Framework laden. 😃
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Also Abt, solche Beiträge wie deiner nerven mich gewaltig.
Ich habe mehrfach geschrieben. Unterschiedliche Rechner, unterschiedliche WPF Anwendungen, Windows 7 in unterschiedlichen Versionen: überall das gleiche Problem.
Ausserdem reicht es beim Windows-Start im Autostart eine kleine WPF Anwendung mit einem ausgeblendetem Window kurz zu starten und sofort wieder zu beenden, damit jede beliebige WPF Anwendung anschließend schnell startet.
Dieses arrogante Bla, Bla kannst du für dich behalten. Ich weiß ganz genau wie .Net funktioniert. Ich habe ein konkretes Problem beschrieben. Hast du das Verhalten getestet??
Wow. Da will man helfen und kriegt so eine Antwort.
Da überlegt man sich zwei Mal, ob man Dir da noch hilft oder versucht zu helfen... Respekt!
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Daher ist jetzt hier auch zu. Für diese Art der Diskussion ist das Forum der falsche Ort. Wir erwarten einen höflichen und respektvollen Umgang miteinander, auch wenn einem eine Antwort gerade nicht in den Kram paßt. Siehe auch [Hinweis] Wie poste ich richtig?, Punkt 1.
Christian
Weeks of programming can save you hours of planning