KISS: Keep it simple, stupid!

Einleitung

Ein altes Sprichwort sagt: "In der Kürze liegt die Würze". Das gilt natürlich auch für die Programmierung. Ein kleineres Programm wird sicher schneller geladen, und läuft im allgemeinen auch schneller.

Ein vergleichendes Beispiel

Es ist schon erstaunlich, dass relativ komplizierte Programme wie rasmol oder xfig einiges schneller starten als ein simpler Texteditor wie kedit. Oder sollte ich eher sagen, dass es eine Schande ist?

Problemanalyse

Schaut man sich den Quellcode von kedit an, sieht das Programm eigentlich recht schlank aus. Auch die Grösse des Ausführbaren Programmes ist minim:

ls -l /opt/kde2/bin/kedit
-rwxr-xr-x 1 root root 3856 Dec 11 12:28 /opt/kde2/bin/kedit
ls -l /usr/X11R6/bin/xfig
-rwxr-xr-x 1 root root 983724 Dec 11 12:28 /usr/X11R6/bin/xfig


Tatsächlich hat der Autor von kedit im Vergleich zu jenem von xfig ein winziges Programm geschrieben. Aber weshalb dauert der Start von ersterem trotzdem so lange?

Die Erklärung wird recht einfach, wenn wir uns mit ldd die Libraries anzeigen lassen, die mit den beiden Programmen verlinkt sind:

für kedit

portablix:/usr/src/current/kdeutils/kedit# ldd /opt/kde2/bin/kedit
        kedit.so.0 => /opt/kde2/lib/kedit.so.0 (0x0ffbb000)
        libkspell.so.3 => /opt/kde2/lib/libkspell.so.3 (0x0ff78000)
        libkfile.so.3 => /opt/kde2/lib/libkfile.so.3 (0x0febb000)
        libksycoca.so.3 => /opt/kde2/lib/libksycoca.so.3 (0x0fe01000)
        libkio.so.3 => /opt/kde2/lib/libkio.so.3 (0x0fd3d000)
        libkdeui.so.3 => /opt/kde2/lib/libkdeui.so.3 (0x0fadb000)
        libkdesu.so.1 => /opt/kde2/lib/libkdesu.so.1 (0x0fa99000)
        libkdecore.so.3 => /opt/kde2/lib/libkdecore.so.3 (0x0f927000)
        libdl.so.2 => /lib/libdl.so.2 (0x0f904000)
        libDCOP.so.1 => /opt/kde2/lib/libDCOP.so.1 (0x0f8c3000)
        libqt.so.2 => /usr/lib/qt/lib/libqt.so.2 (0x0f2b2000)
        libpng.so.2 => /usr/lib/libpng.so.2 (0x0f268000)
        libjpeg.so.6 => /usr/lib/libjpeg.so.6 (0x0f1f3000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x0f1c4000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x0f0db000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x0f0b1000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x0f079000)
        libutil.so.1 => /lib/libutil.so.1 (0x0f057000)
        libz.so.1 => /usr/lib/libz.so.1 (0x0f028000)
        libstdc++-libc6.1-2.so.3 => /usr/lib/libstdc++-libc6.1-2.so.3 (0x0efb0000)
        libm.so.6 => /lib/libm.so.6 (0x0ef63000)
        libc.so.6 => /lib/libc.so.6 (0x0ee4d000)
        /lib/ld.so.1 => /lib/ld.so.1 (0x30000000)
Insgesamt 23 Libraries

portablix:/usr/src/current/kdeutils/kedit# ldd /usr/X11R6/bin/xfig
        libjpeg.so.62 => /usr/lib/libjpeg.so.62 (0x0ff8d000)
        libm.so.6 => /lib/libm.so.6 (0x0ff40000)
        libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x0ff11000)
        libXi.so.6 => /usr/X11R6/lib/libXi.so.6 (0x0fee8000)
        libXaw3d.so.6 => /usr/X11R6/lib/libXaw3d.so.6 (0x0fe62000)
        libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x0fe2d000)
        libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x0fdaa000)
        libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x0fd80000)
        libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x0fd48000)
        libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x0fd19000)
        libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x0fc30000)
        libc.so.6 => /lib/libc.so.6 (0x0fb1a000)
        /lib/ld.so.1 => /lib/ld.so.1 (0x30000000)
Insgesamt 13 Libraries

Offensichtlich dauert das laden der vielen Libraries, die bei KDE Programmen automatisch dazugelinkt werden fast ewig. Zwar verfügt Linux (und einige andere moderne Betriebssysteme) über "Load on Demand" (es werden nur die gerade benötigten Teile eines Programmes geladen), trotzdem geht viel Zeit verloren, weil diese wenigen Bruchstücke von den verschiedensten Orten geladen werden müssen. Dabei entstehen folgende Probleme:

• Der Lesekopf der Festplatte muss sehr oft neu positioniert werden, um Code zu lesen. Zudem können die Teile physikalisch auf der Platte weit auseinander liegen.
• Der Festplattencache wird nahezu wirkungslos, wenn die Teile des Programms sehr weit auseinander liegen.

Schlussfolgerungen

Kleine Programme laufen schneller als grosse.

Wenig Sourcecode schreiben heisst nicht unbedingt ein kleines Programm erzeugen. Moderne Toolkits wie Qt mitsamt KDE Libraries verwöhnen den Programmierer und erzeugen ohne sein Wissen riesigen, langsamen Code. KDE/Qt oder GTK/Gnome sind sicher hervorragend geeignet für komplexe Officepakete oder Webbrowser, die wirklich den gesamten Umfang an Funktionalität ausnutzen. Für kleinere Projekte sind sie aber totaler Overkill. (libqt.so.* belegt alleine schon mehrere Megabyte)

Update: Qt ab Version 4 tritt dem Problem entgegen, indem das Toolkit in mehrere kleinere Libraries aufgeteilt wurde. Somit ist es nun möglich, mit Qt ein Kommandozeilenprogramm zu schreiben, das nicht auch noch den ganzen X11 Code laden muss.