Anwendungs-Startup -- Konzepte?!

[s.h.a.r.k]

Danke schon mal für eure Antworten! Ja, ich mag einen animierten SplashScreen, daher arbeite ich auch mit verschiedenen Threads. Parallelität aber auch daher, da es einen Geschwindigkeitsvorteil bringen kann. Und warum sollte ich meinem CommandProcessor keine Threads beibringen, wenn Dinge parallel laufen könnten? Wenn ich eine so allgemein Lösung implementieren kann, dass sie auf fast beliebige Szenarios anwendbar ist, ist das doch nur ein Vorteil? Klar, ich handle mir hier etwas Komplexität ein, aber ich komme schon fast nicht mehr ohne Threads aus.

@jaenicke: Die Idee, die du da verfolgst ist doch relativ interessant. Ich habe bisher allerdings noch keine so lange Initialisierungsphase(n) zu bewältigen Hast du dir dafür ein universell zu nutzendes Framework geschrieben? Oder hast du das spezielle auf dein Problem angepasst? Wie hast du die Abhängigkeiten zwischen den Modulen gelöst?

[jaenicke]

Zitat von s.h.a.r.k:

Hast du dir dafür ein universell zu nutzendes Framework geschrieben? Oder hast du das spezielle auf dein Problem angepasst? Wie hast du die Abhängigkeiten zwischen den Modulen gelöst?

Die Abhängigkeiten werden in einem zentralen Verwaltungsobjekt über eine Klassenmethode registriert.

Derzeit ist das Konzept stark in dem Programm verwurzelt. Und hat auch ein paar unschöne Stellen. Wenn, dann würde es sich lohnen das zumindest teilweise neu zu schreiben. Bisher war das bei mir aber auch das einzige Programm, das das brauchte. Ich hatte aber schon vor in der Richtung weiter zu forschen. (In den Stunden zwischen 24:00 Uhr und 0:00 Uhr oder so vielleicht... hab einfach keine Zeit...)

[Iwo Asnet]

Das einzige mal, als bei mir eine Anwendung 2-5 Minuten zum Hochfahren brauchte, war eine Adressdatenbank mit ca. 100.000 Einträgen im Spiel, welche eine Livesuche ("while you type") ermöglichte. Das Laden der 20MB und die Query selbst dauern nun mal.

Aber anstatt irgendetwas zu parallelisieren, habe ich die Ladezeit einfach verringert, und zwar auf 20 Sekunden: Einfach die Query optimiert und ADO etwas umgebogen. Das Laden wurde in einen Dienst ausgelagert. Der liest die Daten zum Programmstart ein und hält eine lokale Kopie (natürlich up-to-date) im Speicher. Die eigentliche Anwendung ist nunmehr in 1-2 Sekunden vollständig lauffähig, ohne das im Hintergrund noch etwas werkelt.

Ich kann mir keinen Fall vorstellen, bei dem eine Anwendung mehrere Minuten zum Initialisieren benötigt und wo man nicht durch scharfes Hinsehen (ohne Threads) ansetzen könnte. Was dann als notwendiges Übel übrig bleibt, kann von mir aus in einen Thread (oder in mehrere).

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?

Ich meine, ich kann mir auch parallel von 20 Anbietern jeweils 10 Tonnen Lebensmittel bestellen, obwohl ich ja eigentlich nur ab und an ein belegtes Brot essen will.

Ich will hier nix gegen Threads zum Programmstart sagen, denn schaden tut sowas ja nicht. Auch der Ansatz von Jaenicke ist vollkommen OK: Er vermeidet beim 'on demand fetching' meist das erstmalige Warten, da dies i.A. schon im Hintergrund erledigt wurde: Schick.

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.

[Mavarik]

Die meisten Anwendungsprogramme werden doch einmal gestartet und laufen dann den ganzen Tag...

Dann dauert das jeben mal ein bischen...

Ist ne gute Möglichkeit um den Kunden mal wieder nen schnelleren Rechner zu verkaufen...

In der Zeit wo Du den Start optimierst, könntest Du etwas programmieren was der Kunde gebrauchen kann...

Mavarik

[MGC]

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.
Für mich hört sich dieses Konzept sehr interessant an, da ich selbst Programme am Laufen habe, die aufgrund neuer benötigter Funktionalität mal eben nebenher erweitert werden müssen, ohne zum einen die Start-Performance durch neue PlugIns zu stören und zum anderen eben die Möglichkeit zu nutzen das Grundprogramm schnell an neue Labor-Situationen oder Updates unseres kommerziell erworbenen LIMS-Systems anzupassen und entsrepchend reagieren zu können ohne jedesmal das Hauptprogramm neu stricken zu müssen.
Dabei ist zu beachten das in vielen Betrieben sogar noch Single-Core-Prozessoren im Einsatz sein können.

[Furtbichler]

Zitat von Mavarik:

In der Zeit wo Du den Start optimierst, könntest Du etwas programmieren was der Kunde gebrauchen kann...

[s.h.a.r.k]

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.

Zitat von Iwo Asnet:

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.

Zitat von Iwo Asnet:

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.

Zitat von Mavarik:

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.

Zitat von Mavarik:

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...

Zitat von Mavarik:

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.

Zitat von MGC:

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.

[MGC]

Zitat von s.h.a.r.k:

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.

Genau, die PlugIns werden über einen PlugIn-Manager verwaltet, der über den standardisierten StartUp hinzugeschaltet werden kann. Am besten auch noch zur Laufzeit, falls ein Programm erst später mit PlugIns erweitert wird. Hierbei sind natürlich nur PlugIns von Bedeutung, die eine spätere Erweiterung der Basisfunktonalität darstellen, die bereits beim Programmstart mit initialisiert werden müssen.
In dieser Hinsicht reizt mich demnach das Konzept von Jaennike mit zu berücksichtigen, dass jeder StartUp-Prozess eine Priorität bekommt. Fordert der User gleich nach Erscheinen des Hauptforms nun eine noch nicht initialiserte, bzw. fertig geladene PlugIn-Funktion an, so wird deren Priorität erhöht und somit diese Funktion zuerst geladen/initialisiert.
Darüber hinaus scheint mir dieses Konzept dafür zu sorgen, dass Programme auch leicht von anderen gewartet werden können, da sie sich nicht immer in neue Konzepte einarbeiten müssen. Diese Vorgehensweise würde sich auch sehr gut für den Bereich in dem ich Arbeite anbieten. Ob sich das ganze nun aber auch für Entwickler lohnt, die ihre Software an Kunden vertreiben, weiss ich nicht. Aber das könnte dann ja die Erfahrung beim Einsatz zeigen.

Ich persönlich werde diesen Thread mit Interesse weiter verfolgen.

[MGC]

Zitat von Mavarik:

Die meisten Anwendungsprogramme werden doch einmal gestartet und laufen dann den ganzen Tag...

Dann dauert das jeben mal ein bischen...

Ja, so ein DBMS haben wir bei uns auch im Einsatz. Nervig an der Sache ist nur, dass jeder im Labor sein eigenes Benutzerkonto hat, an das digitale Signaturen angehängt sind und nicht jeder Laborant seinen eigenen Computer hat.

In diesem Fall kann man mit sehr langwierigeb Startprozessen die Kunden auch schonmal verärgern. Nur gut das dieses Bundeslandweit eingesetzte DBMS so kostengünstig war, das man sich die Kunden über die nächsten Jahre hinweg gesichert hat.

Was die Firma jedoch sehr gut hinbekommen hat, waren die Verkaufsgespräche und zusammengestellten Produktpräsentationen. Die haben wirklich überzeugt.
Wenn man jedoch später auch mal andere DBMS im Einsatz gesehen hat und die Kosten-Nutzenrechnungen mal gegenübergestellt hat, dann wusste man erst was los war.