[Gentoo] kde 3.0.2 traaaaaaaaagggg

[raymondw]

Na Gentoo 1.2 geinstalleerd te hebben.
Alles geemerged wat ik nodig heb, KDE starten

KDM starten wacht wacht wacht.... eindelijk een desktop...
Starten van een app duurt ook heel/vrij lang
Naar mijn idee is KDE nu +- 3x zo langzaam
(vergeleken met RH7.3 + KDE 3.0.1)

Ik kan geen fouten ontdekken, standaard prompt lijkt goed te gaan.

Iemand een idee?

[sebas]

Probeer eens de .kde/ in je homedir te verplaatsen an laat kde dan met standaardinstellingen opstarten. Op die manier kom je er makkelijk achter of het daadwerkelijk aan kde ligt of misschien aan een configuratie ervan.

[Apache]

gokje, nog niet met hdparm zitten spelen?

[Verwijderd]

gokje 2: hostname niet ingesteld en geen entry voor de hostname in de hosts file?

(beide in /etc)

[AlterEgo]

[url="http://forums.gentoo.org/viewtopic.php?t=3209&highlight=kde+performance"]Lees dit[/url]

Scheel enorm

[raymondw]

Op zondag 21 juli 2002 17:00 schreef Apache het volgende:
gokje, nog niet met hdparm zitten spelen?

*schaam*
idd overheen gelezen
Toppertje Apache !

Iemand die er interresse in heeft (plak)http://www.gentoo.org/doc/build.html

Super guide

[Verwijderd]

Iemand ook ervaringen met obj-prelink ? En weet ook iemand of dat standaard aanstaat in Gentoo (1.3b)?

[_JGC_]

obj-prelink is deprecated, is gewoon een stuk zooi wat dus niet goed werkt met de nieuwste GCC versies (QT compileerde er hier op kapot, en als ik ./configure --help doe voor KDE, zie ik dat ie deprecated is)

[AlterEgo]

Binutils 2.12 doet ongeveer hetzelfde als objprelink, ook voor andere pakketten dan KDE.
Het proces heet combreloc, als je meer info wil Googlen.
Op Gentoo forums is ook wel iets te vinden.

[Verwijderd]

Yup. Ik krijg onder Slack wel alles gecompileerd met objprelink en GCC 3.1, maar zie geen performance verschil met en zonder meer. Dus het geeft alleen maar risico dat er iets mis gaat in een later stadium... Niet meer nodig dus..

[_Squatt_]

Er is inmiddels wel een objprelink2, maar die heb ik nog niet geprobeerd, vooral omdat gewoon prelink hier prima werkt.

Hierdoor zijn er geen relocaties meer nodig van gesharede libs, en juist dat zorgt voor de lange opstarttijden van bijvoorbeeld KDE.

Wat cijfers:

De eerste konqueror is van een geprelinkt systeem, de tweede niet.

code:

[mh@Scratchy mh]$ LD_DEBUG=statistics konqueror
00907:
00907:  runtime linker statistics:
00907:    total startup time in dynamic loader: 4.945.188 clock cycles
00907:        time needed for relocation: 2.113.200 clock cycles (42.7%)
00907:           number of relocations: 0
00907:    number of relocations from cache: 2.639
00907:       time needed to load objects: 2.518.756 clock cycles (50.9%)

[mh@Scratchy mh]$ LD_DEBUG=statistics konqueror
00915:
00915:  runtime linker statistics:
00915:    total startup time in dynamic loader: 197.636.752 clock cycles
00915:        time needed for relocation: 195.017.041 clock cycles (98.6%)
00915:           number of relocations: 23.406
00915:    number of relocations from cache: 51.263
00915:       time needed to load objects: 2.358.302 clock cycles (1.1%)

En voor kcontrol:

code:

[mh@Scratchy mh]$ LD_DEBUG=statistics kcontrol
00916:
00916:  runtime linker statistics:
00916:    total startup time in dynamic loader: 4.809.520 clock cycles
00916:        time needed for relocation: 1.934.689 clock cycles (40.2%)
00916:           number of relocations: 0
00916:    number of relocations from cache: 2.328
00916:       time needed to load objects: 2.197.986 clock cycles (45.7%)

[mh@Scratchy mh]$ LD_DEBUG=statistics kcontrol
00925:
00925:  runtime linker statistics:
00925:    total startup time in dynamic loader: 163.025.382 clock cycles
00925:        time needed for relocation: 160.719.992 clock cycles (98.5%)
00925:           number of relocations: 21.804
00925:    number of relocations from cache: 49.086
00925:       time needed to load objects: 2.066.960 clock cycles (1.2%)

De tijd die wordt doorgebracht in de dynamische linker wordt een stuk minder (een factor 30-40). En dat merk je in de opstarttijden.

Het enige wat je nodig hebt is een patch voor glibc, een kleine aanpassing in de sources van binutils om het jezelf makkelijker te maken (combreloc standaard aanzetten), en prelink zelf (wat libelf nodig heeft).

Dan hoef je alleen nog maar /etc/prelink.conf aan te passen aan jouw wensen en 'prelink -a -v' te runnen. En je hebt een geprelinkt systeem! _{of je hebt je libs vernield, tijd om die backup te testen...}

Zie ook [url="http://lists.kde.org/?l=kde-devel&m=102190969609172&w=2"]deze[/url] post op kde-devel. Ik heb het zelf gedaan op een lfs systeem, maar op gentoo (waar je ook alles zelf compileert) moet het ook te doen zijn.

[Verwijderd]

Het enige wat je nodig hebt is een patch voor glibc, een kleine aanpassing in de sources van binutils om het jezelf makkelijker te maken (combreloc standaard aanzetten), en prelink zelf (wat libelf nodig heeft)

Werkt dat prelinken en combreloc ook met gcc 2.95, of is dat iets nieuws in versie 3?