Hi!
Mich interessiert programm(ier)technisch und dann verknüpft auf der Hardwareebene, warum es bei den heutigen Prozessoren und SSDs immer noch deutlich schneller und deutlich langsamer startende Software gibt.
Die Frage ist berechtigt, ich weiß allerdings nicht, ob man sie - so wie sie gestellt wird - beantworten kann. Das Problem ist dabei - meiner Meinung nach - der Bezug zur Hardware. Klar spielt die eine wichtige Rolle, aber heute sind viele Programme sehr komplex und dann spielt das Programm an sich eine bedeutende Rolle.
Probramme bestehen heute ja aus mehr als einer einfachen EXE-Datei, wie noch zu DOS oder Win3.1-Zeiten. Programme waren damals recht kompakt und auch schnell, wenn es der eine Entwickler nicht mit dämlicher Programmierung verbockt hat.
Programme heute sind eher komplexe Programmpakete. Um die Entwicklung zu vereinfachen kommen heute viele vordefinierte Programmbibliotheken zum Einsatz. Das ist aus Sicht der Entwicklung praktisch, erfordert dann aber auch, dass die benötigten Komponenten mitinstalliert und dann auch mitgestartet werden.
Die Startreihenfolge der Blibliotheken kann dann schon einen großen Unterschied ausmachen. Einer der Vorteile des IE dürfte einfach daher kommen, dass ein Großteil der Bibliotheken bereits beim Start von Windows geladen wird. Beim Klick auf das Icon geht dann scheinbar schnell, aber der Windowsstart verlängert sich. (Wir erinnern uns alle noch an das Gejammere über die lange Startzeit von Windows und die ganzen Zeitschriften die nur von Optimierungsartikeln dazu gelebt haben...)
Das Laden einer Bibliothek ist nur eine Sache. Sie verwaltet auch i.d.R. irgendwelche Daten, d.h. die müssen nach dem Laden initialisiert werden. Solange ich genau eine Bibliothek nutze, ist das ok. Benötige ich mehrere - wie fast alle Programme heute - kann es zu Abhängigkeiten kommen: die Lade- und Initialisierungsreihenfolge muss eingehalten werden. Kompliziert wird es, wenn eine Bibliothek, andere nachlädt - was auch keine Ausnahme ist. Dann wartet die erste Bibliothek bis die Nachgeladenen initialisiert sind.
OK, damit haben wir die benötigten Bibliotheken im Speicher. Sind wir damit fertig und können das Programm starten?
Nein.
Programme sind heute sehr frei konfigurierbar (und müssen das auch sein). Die Konfigurationsdaten müssen jetzt gelesen werden. Das kann man alles "hart" im Programm kodieren, aber einfacher und flexibler ist es dass mit Hilfe von Skripten zu erledigen. Diese Skripte werden intern ausgeführt (benötigen natürlich Bibliotheken, die dazu geladen und initialisiert werden müssen; hab ich erwähnt das Bibliotheken meistens erst dann geladen werden, wenn sie benötigt werden?).
Zur Beschleunigung der Skriptbearbeitung werden die heute gerne kompiliert und zwar bei jedem Programmstart, es kann sich ja was geändert haben.
Klingt das verrückt?
Es ist normal: Firefox und Openoffice arbeiten genau so (und der Rest der großen "normalen" Programme auch).
Beim Firefox hatte ich angesprochen, dass da Optimierungen zur Startbeschleunigung mit der Version 50 kommen sollen. Die Enwtickler diskutieren dort sehr offen, an was sie konkret arbeiten.
Es wurde festgestellt, dass viel beim Starten von Firefox nicht mehr optimal läuft, was die Geschwindigkeit angeht. Skripte werden zu oft compiliert und die Ladereihenfolge einzelner Komponenten war auch nicht optimal. All das bremst den Start aus und daran wird gearbeitet.
https://bugzilla.mozilla.org/show_bug.cgi?id=1308332
Soetwas schleicht sich ein, wenn sehr viele Köpfe an einem Programm arbeiten. Je nach Hersteller haben das die Entwicklungsabteilungen unterschiedlich gut im Griff. Teilweise gibt es aber auch quasi richtige Reboots/Neustarts mit dem Ziel wichtige Komponenten neu und besser zu schreiben. Der Edge ist aus so einem Neustart hervorgegangen, weil der IE offenbar nicht mehr ausreichend leicht verbessert werden konnte. Beim Firefox wird auch parallel an einer Rendering-Engine gearbeitet. Ziel ist auch hier schlanker und schneller zu werden.
Neben all diesen Softwaredesign-Sachen spielt dann natürlich auch noch die Hardware mit ihren Fähigkeiten eine Rolle. Aber es ist halt auch nur ein weiterer Aspekt in der ganzen Entwicklung von Programmen. Eine Optimierung auf die Hardware birgt immer das Riskiko, dass es auf anderer Hardware nicht mehr passt mit der Optimierung. Also geht man hier auch wieder den weg über Konfigurierbarkeit (und Skriptnutzung, wenn es kompliziert wird).
Das ganze ist ein endloses Optimierungsspiel, mit zuvielen Schaltern und Stellschrauben um da immer optimale Ergebnisse zu bekommen.
Bis dann
Andreas
Borlander
Sovebämse
Knoeppken
Strohwittwer
.
Andreas42
gelöscht_84526
giana0212
Olaf19
