Programovani - shared libraries na Linuxu

[Lubos Lunak]

Ing. Pavel PaJaSoft Janousek wrote:

>> 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.
> 
> No pokud to slinkujete s tolika knihovnama, vite kolik tam muze byt
> potencialne objektu... a vite kolik kostruktoru se zavolalo a kolik
> mista potrebovali pro sve datove oblasti? Jednou z veci vyssi
> programatorske je prave znalost ktera knihovna co poskytuje a tak
> neslinkovavam program s mrakem knihoven, ale pouze s knihovnama, ktere
> potrebuji bud ja nebo knihovny, ktere pouzivam ve svem kodu...

 Rikal jsem to naprosto jasne, kontroloval jsem jednu z tech knihoven, 
nemela ani 4kB na globalni promenne,pritom delala 100kB. Naprosta vetsina 
globalnich objektu v KDE knihovnach jsou jen pointery a vlastni data se 
alokuji az kdyz je treba.

> 
>> 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
> 
> A k cemu takovyto kod potrebuje XIM? Myslim, ze se rozcilujete na
> naprosto nespravnem miste. Az budete mit program, ktery XIM vyuzije,
> opravdu Vas 100kB nezabije, pokud ale ho pouzijete nyni je to plytvani
> mistem...

 Ja o XIM nevim naprosto nic, ale bez XIM v KDE programech nejdou mrtve 
klavesy, jak uz jsem rekl. A bez mrtvych klaves se cesky pise dost spatne. 
(Jestli jsem to spatne pochopil a otazka byla, jakou spojitost ma to pole 
txt[] s XIM, tak ta spojitost je takova, ze oboje pridava bloat do KDE ).

> 
>> to je dobry eufemismus rikat 3 sekundam pri startu textoveho editoru na
>> pentium200 'trochu problem' - jeste i na Thurderbirdu850 je to skoro
>> sekunda).
> 
> Vite neco o efektivite, az bude start editoru operace delana kazdou
> sekundu,nejspise se nad tim nekdo zamysli, pokud je to operace, ktera se
> opakuje tak 1x za hodinu, je lepsi se venovat jine optimalizaci ci
> vyvoji jinym smerem...

 Editor byl samozrejme priklad. Ty priserne startovaci casy se samozrejme 
projevuji pri startu vsech KDE aplikaci ( tedy, projevovaly by se u vsech, 
kdyby se u nekterych programu na to nepouzival takovy jeden hack ).

> 
>> 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.
> 
> Ne, vratme se k SOJ a bude po problemu, resp. nebude, protoze zase
> nekdo bude chtit delat obecneji pouzitelne subrutiny, zase nekdo bude
> chtit vytvaret aspon moduly... kazde ma sve + a - - najit spravne
> optimum nekdy prokaze az nekolikaleta praxe...
> 

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