Leidiges Problem: Aufstarten einer Applikation unter .NET dauert zu lange

[goela]

Wie der Titel es ja schon aussagt: Das Aufstarten von .NET Applikationen dauert einfach zu lange!
Selbst eine einfache Applikation braucht mehrer Sekunden bis diese gestartet wird. Dabei ist nicht die Kompilierung vor der Ausführung schuld, sondern meiner Meinung nach das Laden des .NET Frameworks in den Speicher!

Mich stört dieser Zustand gewaltig. Wer mal versucht hat unter CF.NET (Compact Framework .NET) eine Applikation zu schreiben, wird noch mehr enttäuscht. Eine vergleichbare Anwendung in MFC geschrieben startet beim Klick. Die in .NET braucht sage und schreibe 3-4 Sekunden bis diese gestartet ist.
Aber selbst auf dem Desktoprechner unter .NET ist eine spürbare Verzögerung beim Starten zu bemerken!

Ich möchte gerne mal eure Erfahrungen bzw. Lösungen zu diesem Problem hören.

 

[Norbert Eder]

Nun, das Framework muss nun mal geladen werden. Gleiche Sache bei Java. Wenns Dich so sehr stört, dann wirst Du wohl zu C++ etc. greifen müssen.

Ich hab hier bisher noch keine Probleme gehabt. Man muss sich halt auch ein wenig mit der Interna auseinandersetzen, um gewisse Dinge verstehen zu können ;-)

Norbert

 

[goela]

Man muss sich halt auch ein wenig mit der Interna auseinandersetzen, um gewisse Dinge verstehen zu können

Und was sind die gewissen Internas? Denn die kenne ich ja soweit, was aber nichts an der Sache ändert , dass das Aufstarten einer Anwendung nach meiner Ansicht in .NET einfach miserabel ist!

Beim Compact Framework in meinen Augen sogar absolut indiskutabel ist! Und der Trick am Code welches der Designer generiert hat, manuell noch zu optimieren, damit die Applikation schneller geladen wird - ein absoluter Witz!
Denn hinterher darf bzw. kann man nichts mehr mit dem Designer machen, weil dann die ganzen Optimierungen für die Katz sind.

Soviel zu den Internas!

 

[mage]

Beim Starten ein .Net Programmes wird doch der CLR Code in Maschienencode übersetzt. Ich denke mal, das dadurch die Anwendung so langsam startet. C++ ist ja schon Maschienencode.

Ich denke mal 4 Sekunden sind zu verkraften gerade, wo man heute von Internetanwendungen längere Zeiten gewöhnt ist.
Solange sich nur der Start verzögert und ein flüssiges Arbeiten mit dem Programm aber möglich ist, kein Problem.

 

[Gorcky]

Hallo goela,

Du kannst ja das Programm nicht in CLR-Code, sondern gleich ganz in Maschinen-Code compilieren lassen.
Dann brauchst Du auch kein .NET-Framework mehr auf dem Zielrechner, verlierst aber die portabilität...

 

[goela]

Nun Leute, irgenwie scheine ich wohl der einzige zu sein, den es wirklich kräftig stört, dass eine Anwendung länger braucht bis diese aufgestartet ist.
Nur weil man beim Internet warten muss ist dies für mich bei normalen Applikationen nicht vertretbar!

Hat wirklich jemand schon mal versucht mit ngen.exe das Programm in Maschinencode zu compilieren? Ich schon! Der Zeitgewinn ist gleich Null. Das Framework muss trotzdem erst mal geladen werden. Dadurch kommt die grösste Wartezeit zu stande.

Und zum Thema Portabilität. Ja, wunderbar solange Du ja keine Win32-API Funktionen brauchst! Aber meist kommt man nicht drum herum! Und da geht dann die Portabilität flöten!
Und Portabilität bzw. Plattformunabhängigkeit kann man bisher sowieso vergessen. .NET gibt's nur unter Windows (Mono ausgenommen - WindowsForms werden dort nicht unterstützt).

Versteht mich aber bitte nicht falsch! Ich programmiere jetzt in .NET / C# schon über ein Jahr. Die Sprache und das Framework finde ich wirlkich gut! Man kann sehr schnell gute Applikationen schreiben. Aber für mich hat die Sprache (noch) einfach zu viel Haken - an denen wohl nur ich mir störe!

 

[Gorcky]

Nein, du bist lange nicht der einzige, der sich daran stört.
Aber ich als einer von millonen (oder wie viel auch immer) "zwangsläufigen" Microsoftnutzern habe mich mittlerweile leidgeprüft daran gewöhnt, dass Microsoft scheinbar die Beta-Stufe einspart und lieber noch etwas mehr Geld für seine Produkte verlangt, die dann eben die oben genannten Millionen erst mal beta-testen...

 

[goela]

Ja.... ich bin nicht mehr alleien!
Ich frage mich nur, wie's den Benutzer stört wenn eine Applikation lange braucht zu laden?

 

[Norbert Eder]

Nanana, jetzt übertreibts mal nicht. Ihr sehts da etwas ein wenig falsch.

Es ist von vornherein klar, dass eine Sprache, die auf ein Framework basiert (.NET, Java) länger zum Starten braucht.

Es ist auch klar, dass hier im Bedarf (wenn es wichtig ist, dass eine Applikation schnell startet) auf eine andere Programmiersprache zurückgegriffen werden muss.

Designentscheidung.

Der nächste Punkt:
Was bringts, wenn die Applikation super schnell startet und die weitere Ausführung äußerst lahm ist? Da ist es mir persönlich lieber, dass die Applikation länger startet und dafür dann schnell ist.

Aber wie gesagt, alles eine Frage der Designentscheidung.

 

[goela]

Es ist von vornherein klar, dass eine Sprache, die auf ein Framework basiert (.NET, Java) länger zum Starten braucht.

Mir war es nicht so richtig bewusst. Erst als ich meine ersten Applikationen geschrieben habe! Erst dann bemerkte ich dies. Aber das es gar nicht am kompilieren zu Laufzeit liegt, bemerkte ich erst später! Das Laden des Frameworks dauert lange!

Was bringts, wenn die Applikation super schnell startet und die weitere Ausführung äußerst lahm ist? Da ist es mir persönlich lieber, dass die Applikation länger startet und dafür dann schnell ist.

Stimme ich Dir zu! Aber sind wir mal ehrlich! Auch wenn wohl die .NET den optimalen Code für das System zur Laufzeit produziert, so kenne ich kein Beispiel wo dies auch wirklich von Nutzen ist - auf die Geschwindigkeit gesehen!
Wenn's wirklich schnell sein soll, dann ist eben wieder eine Entscheidung gefragt!

Ich beschäftige mich gerade mit der Programmierung unter Windows CE. Wäre so schön gewesen unter C# in CF.NET zu programmieren. Aber auf einem Pocket PC bin ich der Meinung eine Applikation (Termine, Adressen usw.) sollte sofort aufgestartet sein. Was beim PC lange dauert ist auf dem PPC unter .NET eine Katastrophe! Da hat MS auf jedenfall noch mächtig aufzuholen.