Anwendungs-Startup -- Konzepte?!

[Furtbichler]

Zitat:

Zitat von Mavarik (Beitrag 1143466)

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

:thumb:

[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:

Zitat von Iwo Asnet (Beitrag 1143463)

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:

Zitat von Iwo Asnet (Beitrag 1143463)

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:

Zitat von Mavarik (Beitrag 1143466)

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:

Zitat von Mavarik (Beitrag 1143466)

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:

Zitat von Mavarik (Beitrag 1143466)

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:

Zitat von MGC (Beitrag 1143472)

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:

Zitat von s.h.a.r.k (Beitrag 1143596)

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:

Zitat von Mavarik (Beitrag 1143466)

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.