Nochmals um das ganze klar zu stellen: es geht mir darum, eine einheitliche, leicht zu benutzende Lösung zu finden. Ich habe mir schon oft genug den Kopf darüber zerbrochen, wie ich den Start meines Programms aufbaue, so dass später alles passt. Und wenn ich dann wieder was ändern musste, dann durfte ich wieder Teile umwerfen und neu programmieren.
Weiterhin verstehe ich nicht, das man eine Anwendung schon bedienen kann, aber die notwendige(?) Initialisierung trotzdem 4 Minuten dauert, oder schaufelst Du präventiv alle eventuell notwendigen Daten in den Speicher?
Denk mal an den Firefox: wenn ich den starte, dann werden ja alle zuletzt geöffneten Tabs parallel geöffnet. Ich kann die
GUI schon bedienen, obwohl nicht alle Websiten fertig geladen sind. Es wird immer Szenarios geben, in denen sowas sinnvoll sein kann.
Aber bevor man zu irgendwelchen Tricks greift, um etwas schneller zu machen (Threads sind hier 'Tricks'), sollte man mal prüfen, ob das nicht eleganter geht. Ebenso wie Neo4a bin ich der Ansicht, das eine schlechte Performance zuforderst mit einer guten Struktur bekämpft werden kann.
Um die Performance geht es hier eher sekundär. Der Start wird deswegen nicht wesentlich langsamer, nur weil ich einen CommandProcessor einbaue, der mir eine Verwaltung abnimmt. Dass ich mir ein wenig Einbußen mit ins Bot hole nehme ich sehr gerne in Kauf, dafür erhalte ich aber eine wesentlich bessere Bedienung
imho.
Die meisten Anwendungsprogramme werden doch einmal gestartet und laufen dann den ganzen Tag...
Dann dauert das jeben mal ein bischen...
Wie schon gesagt, es geht eigentlich eher weniger um die Dauer, als um das Wie. Die ganzen Office-Pakete (Word, Excel etc.) werden einen einheitlichen Startprozess haben und die Anwendungen laufen bestimmt nicht den ganzen Tage über.
Ist ne gute Möglichkeit um den Kunden mal wieder nen schnelleren Rechner zu verkaufen...
Nimm es nicht persönlich, aber das ist mal eine recht seltsame Einstellung...
In der Zeit wo Du den Start optimierst, könntest Du etwas programmieren was der Kunde gebrauchen kann...
Wenn ich einmal ein Framework zu grunde liegen habe, in das ich mal mehr Zeit investiert habe, so kann ich das immer und immer wieder verwenden, werde somit auf die Dauer effizienter. Es geht, wie schon erwähnt, nicht um die Effizienz, denn die nimmt nicht viel zu und auch nicht viel ab. Das was der Kunde brauch ist allerdings ein System, das leicht wart- und änderbar ist. Wenn ich das Framework nun bei 10 verschiedenen Anwendungen am Laufen habe und alles stabil ist, so brauche ich mich nicht mehr in individuelle Startupprozesse einarbeiten, wenn ich da mal wieder was ändern bzw. erweitern müsste. Ich müsste lediglich eine weitere Command-Klasse schreiben und diese dann nur über Attribute passende definieren -- der Rest geschieht vollkommen automatisch.
Also für mich hört sich das eher nach einem Konzept für Programme an, welche durch ein PlugIn-System beständig erweitert werden kann und man dennoch keine Performance-Einbußen im Startvorgang hinnehmen muss.
In so fern Plugins hier fest verdrahtet sind, so kann könnte man das (fiktive) Framework sicherlich auch nutzen. Hier käme dann auch die Stärke der Parallelisierung stark zum Vorschein, in so fern die Plugins nicht voneinandere abhängen. Alternativ würde sich hier allerdings eher ein PluginManager anbieten -- kommt aber wiederum aufs Konzept an, welches mit dem Plugin-System verfolgt wird.
»Remember, the future maintainer is the person you should be writing code for, not the compiler.« (Nick Hodges)