linker.html

Linker Optimierung

Reihenfolge der Objekte in Libraries

Ein Problem beim GNU Linker ist die Reihenfolge, in der Objeckte in Libraries gelinkt werden. Funktionen werden in der Reihenfolge in Objekte gepackt wie sie im Sourcecode vorkommen. Diese Objekte werden dann in der Reihenfolge in Libraries gepackt, in der sie beim Aufruf des Linkers angegeben wurden.

Gute, professionelle (und teure) Produkte unter anderen Plattformen können seit einiger Zeit Programme starten, die Erstaufrufsreihenfolge der Funktionen erkennen und dann im zweiten Durchlauf in der Reihenfolge in die Libraries packen. Weil nun immer schön der Reihenfolge nach von der Platte gelesen wird ist der Plattencache effektiver und die Programme starten schneller.

Ab Version 3.1 bringt auch der GNU Compiler die Möglichkeit der Optimierung gemäss Laufzeitprofilierung. Siehe dazu auf der GCC Homepage Infrastructure for Profile Driven Optimizations

Bei zufälliger Anordnung der Objekte in den Libraries kann es vorkommen, dass die erste aufgerufene Funktion am Anfang der Library ist, und die nächste am Ende. Der Plattencache, der einen Teil des Anfangs bereits gelesen hat greift nun nicht und der Lesekopf muss erst positioniert werden, um die als zweite aufgerufene Funktion zu lesen.

Unter Linux könnte man diese Ordnung von Hand im Makefile korrigieren, ich weiss aber nicht ob sich alle Programmierer dieser Problematik bewusst sind.

Hilfsmittel zur anordnung von Objekten in Binaries

• cord / pixie
  (nur für SGI-IRIX)
• grope (GNU Rope)
  Ein GNU-Programm nach dem Vorbild von SGIs cord.
• fur
  Function Rearranger von SCO
• Für Solaris gibt es von Sun auch etwas ähnliches, der Name ist mir leider entfallen.

Hinweise für Toolkitprogrammierer

Die Libraries von Toolkits sollten in drei Gruppen aufgeteilt werden:

• Funktionen, die beim Start von jedem Programm schon gebraucht werden bevor der Benutzer eine Eingabe macht.
• Funktionen, die bei den meisten Programmen während dem Betrieb benötigt werden.
• Funktionen, die nur selten oder nur von sehr komplizierten Programmen benötigt werden.

Somit wird sichergestellt, dass beim Start eines Programmes nur die nötigsten Funktionen in den Diskcache geladen werden und das Programm somit schneller geöffnet wird. Bei zufälliger Verteilung der Funktionen muss im schlimmsten Fall alles geladen werden und der Code passt kaum mehr in den Cache.

Bei kleinen, einfachen Programmen wird somit auch während dem Betrieb der Cache nicht für unbenutzte Funktionen verschwendet.

Des weiteren lassen sich die Libraries bei sehr komplexen Toolkits noch in Kategorien für bestimmte Programmgattungen ordnen. Es wäre schade, wenn beim Start eines Bildbetrachters zum Beispiel unbenutzter Code für POP3 oder IMAP im read-ahead Cache landet.

Links zu verwandten Themen

• Making C++ ready for the desktop
  Analyse zum Problem der "relocations" im KDE-Projekt von Waldo Bastian
• C++ and shared libraries
  Analyse zum Speicherverbrauch durch KDE von Lubos Lunak