# Lohnt sich prelink?

## reyneke

Hi.

Prelinking ist ein Thema, das in der letzten Zeit immer öfter in den Foren auftaucht. 

Wenn ich das  Prelink Howto richtig verstehe, dient diese Methode ausschließlich dazu, die Startzeiten der Programme zu verkürzen.

Die Binaries selbst werden allerdings größer; übt sich das nicht auf die Performance aus? 

Es wäre hilfreich zu wissen, um welchen Faktor sich die Binär-Dateien vergrößern.

Kann mir vielleicht jemand von seinen Erfahrungen berichten?

Danke schonmal.

Gruß,

reyneke.

----------

## hds

IMHO wirkt sich das auch auf den RAM aus - zumindest wenn du KDE einsetzt. ich habe deutlich weniger "kdeinit" prozesse als ohne prelinking.

probiers doch einfach aus, du kannst ja wieder zurueck, wenn es dir nicht zusagt. zumindest nachteile konnte ich persoenlich nicht feststellen.

----------

## EnricoHorn

Das hängt IMHO auch von deinem Rechner ab. Ich hatte z.B. bis vor kurzem eine Duron 800. Bei dem ging z.B. das Starten von KDE nach prelink doch ein ganzes Stück schneller. Mit meinem Athlon64 3200+, den ich jetzt habe, merke ich allerdings kaum einen Unterschied. Ok, ich habe nicht nachgemessen, aber rein subjektiv ist das so.

----------

## z4Rilla

hab ein P4 1.8 GHz und irgendwie merk ich keinen unterschied...

----------

## ChrisM87

Hi,

hab es auch mal ausprobiert und keinen allzu großen Unterschied festgestellt. Prelinking wirkt sich ja ohnehin nur auf den Start aus und nicht auf die Laufzeitperformance und die kritischen Sachen wie z.B. Konqueror laden auch so schnell (KDE kann auch immer einen Konqueror unsichtbar im Hintergrund halten, damit er noch schneller da ist, siehe Kontrollzentrum).

ChrisM

----------

## hds

 *ChrisM87 wrote:*   

> Prelinking wirkt sich ja ohnehin nur auf den Start aus und nicht auf die Laufzeitperformance 

 

dann mach doch mal ein "ps ax | grep kdeinit" mit und ohne prelinking, und sei ueberrascht.

----------

## Jinidog

Ich habe auf einem K6-2 450, einem Thunderbird 1200 und einem XP 2800+, als auch einem P4 2,4 GHz keine deutlichen Performancegewinne verspürt.

Hab's aber auch nie richtig verglichen.

Ich prelinke trotzdem, schadet ja nicht.

----------

## moe

 *hds wrote:*   

>  *ChrisM87 wrote:*   Prelinking wirkt sich ja ohnehin nur auf den Start aus und nicht auf die Laufzeitperformance  
> 
> dann mach doch mal ein "ps ax | grep kdeinit" mit und ohne prelinking, und sei ueberrascht.

 

Ich dacht immer Performance spürt man, und siehts nicht an irgendwelchen Prozesslisten.   :Laughing: 

Ich hatte vor gut einem halben Jahr auch mal Prelink probiert, aber auch keinen Unterschied bemerkt, und habs dann wieder gelassen. Ich denke mal richtig wirken tuts nur auf eher statischen Systemen, wie z.B. der Knoppix-CD, wo man das auch bis aufs letzte optimieren kann. Bei einem System was ständig geupdated wird, ist der Aufwand immer neu prezulinken imho höher als der Gewinn.

Gruss Maurice

----------

## ChrisM87

Hi,

 *hds wrote:*   

>  *ChrisM87 wrote:*   Prelinking wirkt sich ja ohnehin nur auf den Start aus und nicht auf die Laufzeitperformance  
> 
> dann mach doch mal ein "ps ax | grep kdeinit" mit und ohne prelinking, und sei ueberrascht.

 

ja, und woher weißt du, dass der kdeinit-Wrapper jetzt so unheimlich viel Speicher braucht? (Prozessorauslastung braucht er nämlich keine, ist ja nur ein Wrapper, der den Start koordiniert)

ChrisM

----------

## hds

 *ChrisM87 wrote:*   

> 
> 
> ja, und woher weißt du, dass der kdeinit-Wrapper jetzt so unheimlich viel Speicher braucht? 

 

2,6-2,8% memory pro kdeinit process sind es bei mir. mach halt ein "ps aux | grep kdeinit"

vor dem prelinking hatte ich gut und gerne 10-15 dieser prozesse. nach dem prelinking max. 4-6.

----------

## reyneke

Danke erstmal für eure Antworten.

OK, also wirklich nur die Startzeiten verkürzen sich. Jetzt müßte ich bloß noch wissen, ob sich der Compile/Emerge-Prozeß spürbar verlängert und ob die Binaries merklich größer sind, um abzuschätzen, ob sich das rentiert.

Bei OOo und KDE würd's mich schon reizen. Kann man prelink auch nur für einzelne ebuilds aktivieren?

----------

## hds

 *reyneke wrote:*   

> 
> 
> OK, also wirklich nur die Startzeiten verkürzen sich.
> 
> 

 

offensichtlich hattest du meinen beitrag nicht gelesen, oder RAM spielt bei dir keine rolle? speziell kuerzere startzeiten konnte hier kaum jemand feststellen  :Wink: 

 *reyneke wrote:*   

> 
> 
> Kann man prelink auch nur für einzelne ebuilds aktivieren?

 

prelink hat absolut nichts mit ebuilds zu tun, das durchsucht deine platte. dort prelinked es alles was es kann, bzw. was nicht in /etc/env.d/60prelink ausgeklammert wurde. wirf mal ein "man prelink" ein, und lies es nach. selbstverstaendlich kannst du einzelne binarys prelinken, man muss nicht "-avmR" nutzen. beispiel befindet sich in der manpage. auch ein beispiel, um ein backup der org version abzulegen, somit sieht man den groessenunterschied in der filesize.

PS: und denk an das "pic" USEflag, sofern noch nicht vorhanden. danach glibc neu compilen, bzw. mit --newuse nachschauen, welche applications noch von dem flag gebrauch machen. sind aber ausser glibc nicht viele (gzip und noch eines bei mir).

siehe auch:

https://forums.gentoo.org/viewtopic.php?t=253519&highlight=prelink+nvidia

der tip im obigen thread mit den nvidia treibern funktioniert uebrigens wunderbar  :Wink: 

good luck!

----------

## moe

 *hds wrote:*   

> 
> 
> 2,6-2,8% memory pro kdeinit process sind es bei mir. mach halt ein "ps aux | grep kdeinit"
> 
> vor dem prelinking hatte ich gut und gerne 10-15 dieser prozesse. nach dem prelinking max. 4-6.

 

Wo wir wieder bei einer Frage wären, die mir noch keiner wirklich beantworten konnte:

Wenn mehrere (gleiche) Prozesse, gestartet sind, zeigt ps aux dann den Speicherbedarf pro Prozess, oder insgesamt für alle gleichen Prozesse?

Hab gerade kein KDE hier, ums gleich mal mit diesem Beispiel zu testen, und bei meiner aktuellen Prozessliste, gibts nur agetty und distccd als "Multiprozesse" und diese haben auffallend genau alle denselben Speicherbedarf..

Gruss Maurice

----------

## hds

```

bash-2.05b$ ps aux | grep kdeinit

hds      3605  0.2  2.4 24272 9404 ?        Ss   09:24   0:00 kdeinit Running...

hds      3610  0.2  2.5 25280 9864 ?        S    09:24   0:00 kdeinit: klauncher

hds      3722  0.4  3.7 32072 14528 ?       S    09:24   0:00 kdeinit: knotify

hds      3733  0.0  2.7 25760 10520 ?       S    09:24   0:00 kdeinit: kio_file file /tmp/ksocket-hds/klauncherwxBNoa.slave-socket /tmp/ksocket-hds/kdesktopOSAWdb.slave-socket

bash-2.05b$

```

----------

## reyneke

 *moe wrote:*   

> 
> 
> Hab gerade kein KDE hier, ums gleich mal mit diesem Beispiel zu testen, und bei meiner aktuellen Prozessliste, gibts nur agetty und distccd als "Multiprozesse" und diese haben auffallend genau alle denselben Speicherbedarf..
> 
> 

 

Wenn ps den Speicherbereich insgesamt anzeigte, müßte dieser sinken wenn Du einen der Prozesse killst, oder? Das ist zumindest bei mir nicht der Fall - mithin wird der Speicherbedarf pro Prozess angezeigt. Daß der bei mehreren Instanzen desselben Programms exakt gleich groß ist, ist IMO nicht verwunderlich.

HTH,

reyneke.

----------

## c07

Den angezeigten Speicherverbrauch kann man nicht einfach addieren. Da sind jeweils alle Libraries dabei, die geladen sind, und speziell bei gleichen Prozessen sind das natürlich jeweils die selben, die auch nur einmal Speicher brauchen, abgesehn vom dynamischen Verbrauch. Z.B. hat bei mir jeder kdeinit-Prozess die 6784 KB von libqt-mt.so, die sowieso geladen ist. Nur von den zugehörigen 256 KB Daten wird wohl jeder Prozess eine eigene Kopie haben.

Wie sich der Speicherverbrauch von einem Prozess aufschlüsselt, lässt sich mit 

```
pmap <pid>
```

 ermitteln.

----------

## hds

nunja, vielleicht sollte man mal eine art SummaSummarum geben auf die frage:"lohnt sich prelink"?

IMHO sollte die antwort lauten:"es lohnt sich fuer einige leute, geschadet hat es bisher niemandem - probier es einfach aus"?   :Laughing: 

wie auch immer, es macht weitaus mehr sinn als dieses geschrei nach NPTL, das nutzt naemlich wirklich bisher niemandem, es sei denn er macht sehr viel mit java applications rum. nur und wirklich nur dann macht nptl heute sinn!

was auch nett ist, perl mit ithreads zu compilen.

wie auch immer, ich sehe keine nachteile von prelink, nptl und ithreads. vorteile kann ich persoenlich lediglich in prelink erkennen, da ich wenig mit java und perl rummache.

----------

## Fauli

Noch eine Ergänzung: Bevor man sich entscheidet, Prelink zu deinstallieren, sollte man mit "prelink --undo" den alten Zustand aller Binarys wiederherstellen.

Der Grund: Portage prüft beim Unmergen eines Pakets die MD5-Prüfsummen der installierten Dateien. Wenn sich die Prüfsumme von der bei der Installation des Pakets unterscheidet, wird die entsprechende Datei nicht gelöscht. (Es erscheint dann "--- !md5" vor dem Dateinamen.) Das Binary und damit die Prüfsumme ändert sich aber durch das Prelinken!

Portage muss also beim Unmergen erst einmal das Prelinken rückgängig machen. Erst danach kann die Prüfsumme berechnet und verglichen werden. Dazu benötigt Portage aber ein installiertes Prelink.

Um es kurz zu fassen: Ohne installiertes Prelink deinstalliert Portage keine mit Prelink behandelte Binarys.

----------

## hds

 *Fauli wrote:*   

> 
> 
> Um es kurz zu fassen: Ohne installiertes Prelink deinstalliert Portage keine mit Prelink behandelte Binarys.

 

interessant, habe ich nicht gewusst! ok, das prelink ebuild hatte ich eh nie unmerged (tut ja nicht weh), aber dennoch gut zu wissen!

gruess mir meine alte heimatstadt  :Wink: 

----------

