enttäuscht über prelink (für Leute die es sich überlegen)

[BlackEye]

Ich hab letztes WE in einer "Megaaktion" meine glibc auf die neuesten Stand gebracht samt gcc. (hat insgesamt bestimmt > 24h gedauert)
Nun laut beschreibung ein "emerge prelink" und ein "prelink -afmR". Nach eine kurzen Weile (~5 Mins) war er auch schon fertig.
Nun noch schnell neu gebootet und geguggt, was es gebracht hat ..
Null Also wenn das überhaupt einen Vorteil gebracht hat, dann wohl nur irgendwo hinter dem Komma. Ich bemerke vielleicht ein subjektives schneller starten von dem einen oder anderen Programm. Das sind aber
1) eh nur kleine Programme wie "mldonkey_gui"
2) nur sehr wenig Programme

Bei den Programmen, wo ich mir einen schnelleren Start erhoffte (wie z.B. das KDE startup, Konqueror, galeon, mozilla, etc...) tat sich nix. Gar nix ..

mein Fazit: Aufwand von Umstellung auf neue glibc + prelink >> gesparter Zeitaufwand beim starten von Programmen
Also für mich hat es sich überhaupt nicht gelohnt ...

Das ist nur so ein Thread für Diejenigen, die es sich noch überlegen umzusteigen

Gruß,
Black

[jew.de]

Hi,

ich habe mich mit prelinking nur oberflächlich befasstr, aber musst Du nicht noch irgentwo den Pfad zu dem Programm angeben, welches ge-prelinkt werden soll?

Tobi

[BlackEye]

jo klar, das steht alles in der /etc/prelink.conf drinn. Die ist ja auch soweit standardmässig gut eingestellt
Das komplette kde Verzeichnis z.B. geht er durch

[lanius]

Ich habe das gleiche Gefühl wie BlackEye, kaum Geschwindigkeitsverbesserungen, dafür sind aber die Binarys wesentlich größer geworden!

[Dimitri]

Das einzige was mir aufgefallen ist, (kann auch nur subjektiv sein) dass das kompilieren schneller geht. Ich war in letzter Zeit oft verwundert warum er schon fertig war obwohl der ebuild früher eigentlich schon deutlich länger gedauert hat. Kann aber auch nur Einbildung sein...

Dim
_________________
Visit kde-forum.de

[phelan]

Ich habe ebenfalls keinen Geschwindgkeitsvorteil bemerkt.

Das einzige was ich bemerkt habe, ist dass mein Speicher (512MB) ständig voll ist. (Ist zwar ja eigentlich auch ein bisschen der Sinn der Sache)

[itsme]

Also auf meinem System (1GHz Pentium) starten KDE & Mozilla schon "bemerkbar" schneller aber der Gewinn ist nicht so sonderlich groß, da habe ich dann doch lieber etwas mehr Platz auf der Platte

[Hagbard Celine]

Mittlerweile ist fast ein Jahr vergangen, aber die Threads zu Prelinking sind immer noch recht selten und wenig ergiebig. Deshalb nochmal an dieser Stelle...

Nachdem Prelinking sich unter anderem über die libmng und libtiff beschwert hat, habe ich sie nochmal mit -fPIC neu übersetzt, Erfolg gleich Null.

Dann auch nochmal komplett KDE neu übersetzt, weil irgendwo die Rede war, dass bei statisch gelinkten Sachen auch diese neu übersetzt werden müssen, Erfolg gleich Null.

Wenn ich mir mit LD_DEBUG=statistics ansehe, was sich getan hat, dann sehe ich bei Programmen wie tar und dd tatsächlich einen Unterschied, die Anzahl der Relocations ist 0. Bei KDE-Programmen sehe ich aber keinen Unterschied.

Hier mal die Ausgabe für LD_DEBUG=statistics konqueror:

1799: runtime linker statistics:
1799: total startup time in dynamic loader: 342973648 clock cycles
1799: time needed for relocation: 332649916 clock cycles (96.9%)
1799: number of relocations: 25506
1799: number of relocations from cache: 54782
1799: time needed to load objects: 9681832 clock cycles (2.8%)

Postet doch mal eure Werte, so zum Vergleich!

Hat noch jemand eine Idee, warum sich KDE-Programme nicht prelinken lassen? Und das obwohl prelink sagt es würde das Programm erfolgreich prelinken. Die Programm werde zwar grösser, aber die Bootzeit hat sich eher verschlechtert... hat jemand schon unterschiedliche CFLAGS versucht?

Ich erinnere mich noch, das es früher mit dem OBJPRELINK, dass man aber schon beim Configure angeben musste, eine deutliche Verbesserung gab...

hc