Anwendungs-Startup -- Konzepte?!

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