Programovani - shared libraries na Linuxu

[Lubos Lunak]

Stanislav Meduna wrote:

> Lubos Lunak schrieb in Nachricht <9n0rv7$30ut$1 na ns.felk.cvut.cz>...
> 
>> Zatimco na Unixech pouzivany ELF system nas dostava
>>do novych casu, kdy  primitivni programek slinkovany s hodne
>>knihovnami zere kvanta pameti jen pro ty knihovny,
> 
> A to ako preco? Ak kod nikto nepotrebuje, v realnej pamati nebude
> (az na tie stranky s odkazmi). Navyse ak su to kniznice, ktore
> uz tak ci tak niekto pouziva, spotreba pamati sa nezvysi vobec.
> 
> Kolko chcu virtualnej pamati je mi vcelku jedno.

 No tak takhle naivni jsem byl taky. Do te doby nez jsem to zkusil zmerit. 
Muzeme si to klidne spolu zkusit znovu, potreba je jen KDE2.x a g++. Takze, 
napiseme primitivni program, neco jako

#include <unistd.h>
int main()
    {
    sleep( 30 );
    }

a prelozime gcc test.cpp -O2 a spustime a zmerime spotrebu nesdilene (tj. 
per-process) pameti. Ja to pocitam v 'top' jako rozdil SIZE-SHARE, jestli 
nahodou nekdo zna lepsi zpusob, rad se poucim. No ne, 56kB, a to je to 
slinkovane jen s glibc. No nic, zkusime misto gcc pouzit g++, navic 
prilinkuje libstdc++. Oops, najednou je to 108kB (+52kB). No, aby to bylo 
zajimavejsi, zkusime g++ test.cpp -O2 -lkparts -L/opt/kde2/lib , to 
slinkuje ten maly smesny program asi tak se skoro triceti knihovnami. Tak, 
a kdo ted nameril mene nez 600kB (me to vychazi 636), tak at mi da vedet, 
me by zajimalo, jak to dokazal.
 Jednu z tech knihoven (libkdeui) jsem dokonce rucne kontroloval, nenasbira 
se tam ani na 4kB globalnich promennych a podobnych veci, pritom libkdeui 
dela rozdil 100kB, takze 96kB z toho jde na vrub tomu, co vyplodi gcc a 
binutils. No neni to nadhera ? Pak ze KDE team pise neoptimalizovany kod a 
trapaci v ruznych prispevcich vsude mozne trousi blbosti o minimu 256MB na 
beh KDE a podobne.
 Kdyby to naivni tvrzeni nahore byla pravda, KDE na 64MB masine lita jak z 
praku. A kdyby v KDE nebyl nejaky ten workaround na tahle priserna cisla, 
nejspis by se na 64MB masine nedalo pouzivat naprosto vubec.

 Ted bych jeste mohl rict treba neco o tom, proc skoro vsechno v KDE se 
preklada s -fno-exceptions, nebo jak skvele konstatni je v ELF PIC kodu vec 
jako 'const char* const txt[] = { "raz", "dva" };', pripadne o tom ze kazda 
KDE aplikace spotrebuje pres 100kB pameti pri inicializaci XIM ( to je 
takova vec, ktera je pro nas dobra asi jen na to, aby fungovaly mrtve 
klavesy ), ale myslim, ze uz dalsimi detaily nebudu obtezovat. Jednak bych 
pri tom asi hodne nadaval, a tady s tim asi stejne nikdo nic neudela ( nebo 
snad ano ? ). Kdyz si nekteri, kdo si tohle precetli, priste odpusti 
blaboly o KDE, budu si rikat, ze sem to sem nepsal zbytecne.
 
> 
>>nemluve o startovacim casu.
> 
> Ano, toto je na Linuxe trochu problem - akurat neviem ci je to
> odstranitelny performance problem v dynamickom linkeri, alebo
> dan za modularitu (spusta navzajom previazanych malych kniznic,
> z ktorych ma potom linker hlavu v smutku).

 To je odstranitelny performace problem v dynamickem loaderu a uz se resi, 
po tom, co jeden z KDE vyvojaru napsal 
http://www.suse.de/~bastian/Export/linking.txt a pustil to do sveta (jinak, 
to je dobry eufemismus rikat 3 sekundam pri startu textoveho editoru na 
pentium200 'trochu problem' - jeste i na Thurderbirdu850 je to skoro 
sekunda).

> 
[snip]

 Kdyby si snad nekdo chtel vazne o tehle vecem podiskutovat, klidne. A 
takovehle veci samozrejme nejsou problemem jen KDE. Ona ta Mozilla asi 
nebude az takova Bloatzilla, a StarOffice si asi taky nemuze za ten dlouhy 
start jen sam.


 Lubos Lunak
--
 l.lunak na email.cz ; l.lunak na kde.org
 http://dforce.sh.cvut.cz/~seli