AGB  ·  Datenschutz  ·  Impressum  







Anmelden
Nützliche Links
Registrieren

Anwendungs-Startup -- Konzepte?!

Ein Thema von s.h.a.r.k · begonnen am 28. Dez 2011 · letzter Beitrag vom 29. Dez 2011
Antwort Antwort
Seite 2 von 2     12
Furtbichler
(Gast)

n/a Beiträge
 
#11

AW: Anwendungs-Startup -- Konzepte?!

  Alt 28. Dez 2011, 21:59
In der Zeit wo Du den Start optimierst, könntest Du etwas programmieren was der Kunde gebrauchen kann...
  Mit Zitat antworten Zitat
Benutzerbild von s.h.a.r.k
s.h.a.r.k

Registriert seit: 26. Mai 2004
3.159 Beiträge
 
#12

AW: Anwendungs-Startup -- Konzepte?!

  Alt 29. Dez 2011, 13:55
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)
  Mit Zitat antworten Zitat
Benutzerbild von MGC
MGC

Registriert seit: 15. Mai 2008
Ort: Helsa
106 Beiträge
 
Turbo Delphi für Win32
 
#13

AW: Anwendungs-Startup -- Konzepte?!

  Alt 29. Dez 2011, 14:53
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.
Marc
Programmieren ist wie Chemie:
1. Wenn man alles einfach nur zusammenschmeisst kommt es zu unerwarteten Reaktionen.
2. Wenn es plötzlich anfängt zu qualmen, muss man eben noch mal von vorn anfangen.
  Mit Zitat antworten Zitat
Benutzerbild von MGC
MGC

Registriert seit: 15. Mai 2008
Ort: Helsa
106 Beiträge
 
Turbo Delphi für Win32
 
#14

AW: Anwendungs-Startup -- Konzepte?!

  Alt 29. Dez 2011, 15:03
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.
Marc
Programmieren ist wie Chemie:
1. Wenn man alles einfach nur zusammenschmeisst kommt es zu unerwarteten Reaktionen.
2. Wenn es plötzlich anfängt zu qualmen, muss man eben noch mal von vorn anfangen.
  Mit Zitat antworten Zitat
Themen-Optionen Thema durchsuchen
Thema durchsuchen:

Erweiterte Suche
Ansicht

Forumregeln

Es ist dir nicht erlaubt, neue Themen zu verfassen.
Es ist dir nicht erlaubt, auf Beiträge zu antworten.
Es ist dir nicht erlaubt, Anhänge hochzuladen.
Es ist dir nicht erlaubt, deine Beiträge zu bearbeiten.

BB-Code ist an.
Smileys sind an.
[IMG] Code ist an.
HTML-Code ist aus.
Trackbacks are an
Pingbacks are an
Refbacks are aus

Gehe zu:

Impressum · AGB · Datenschutz · Nach oben
Alle Zeitangaben in WEZ +1. Es ist jetzt 12:09 Uhr.
Powered by vBulletin® Copyright ©2000 - 2022, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2021 by Daniel R. Wolf