KDE tipy a triky

27.8.2006 22:15 | Přečteno: 3487× | KDE |

Takovych lidi si tu porad stezuje, ze KDE aplikace startuji hodne pomalu, kdyz se pouzivaji mimo KDE. Reseni je proste: Pouzivat je v KDE ;). A nebo si trosku pomoct. My za to totiz vlastne ani moc nemuzeme ...

• KDE knihovny jsou dost velke a proste cokoliv velke obvykle potrebuje trosku vic vykonu nez neco male. S tim se ale moc toho delat neda. Chapu, ze i v dnesnich dobach harddisku s desitkami GB muze nekterym lidem porad vadit, ze kvuli kdelibs by museli smazat jedno cdcko grabnutych mptrojek a mozna jeste drobet vic i kvuli zavislostem, ale co uz se da delat. Knihovny KDE usnadnuji praci stovkam programatoru a osekat je by bylo, jak se pravi v anglictine, jako strelit se do nohy. A zmensovat zavislosti a potrebne casti z jinych knihoven si naprogramovat sami, to by hned bylo jak trpime NIH a podobne (jakoze uz i tak tohle spousta lidi vytahuje, jako by nemeli nic lepsiho na praci). KDE knihovny velke byly, jsou a budou a asi neni rozumny zpusob, jak s tim neco udelat. Za vyhody se plati tim, ze je tu velky pocatecni skok.
• Tim, ze jsou knihovny velke, jejich nacteni do pameti uz jen samo o sobe neco trva. I kdyz harddisk zvladne treba 50MB/s, porad nahrat par desitek MB do pameti chvilku trva. I kdyz, tohle je vlastne jen malicka cast problemu.
• Dalsi a velky problem je ten, ze vykon cteni z disku rapidne klesa, pokud se misto velkych bloku dat cte hodne malych nebo se data nectou linearne ale napreskacku. Ackoliv uz nekolik distribuci ma patch v glibc na linearni precteni cele knihovny misto strankovani dle potreby (coz je sice hezke teoreticky, ale z hlediska rychlosti nacitani je rozdil rychlosti docela dobre meritelny), zadny takovy patch se (AFAIK) zatim nikomu protlacit do oficialni glibc nepovedlo. Stejne tak je tady dobre, ze kdelibs jsou nekolik vetsich knihoven nez hodne malych, ackoliv tohle konkretne se uz asi v tech ostatnich vecech ztrati.
• Dynamicky linker ld.so, tj. ta vecicka, ktera se stara o pripravu sdilenych knihoven, nez je muze program pouzit, je uz notoricky znama svym spatnym vykonem, hlavne u C++ programu. Pomalost zpusobuje nejen to, ze C++ knihovny maji hodne dlouhych symbolu, ktere ld.so spatne zvlada, ale i velky pocet knihoven zpusobuje zpomaleni (zdvojnasobeni poctu sdilenych knihoven, ktere program pouziva, muze znamenat az dvojnasobne zpomaleni). Dalsi duvod byt rad, ze KDE knihovny jsou velke a je jich malo. Mimochodem, je docela ironie, ze protoze GNOME naopak pouziva hodne malych knihoven, tak uz taky zacinaji narazet na nektere tyhle problemy, prestoze pouzivaji jen obycejne C. Ackoliv se do glibc dostalo uz nekolik vylepseni typu combrelloc nebo ted nove hashstyle (coz taky muselo docela trvat, vyvojari glibc asi obcas silne trpi na NIH), jsou to spis jen mensi vylepseni a nic zasadniho se zda se nechysta. Michael Meeks se zatim dost neuspesne snazi, aby se s nim o -Bdirect vubec jen bavili a prelink, at je obecne povedomi jakekoliv, prinasi skoro tolik problemu jako jich resi a navic neresi ani vsechny puvodni problemy (treba pro OpenOffice.org je prelink v soucasnem stavu prakticky nepouzitelny).
• KDE pouziva cache zvanou KSycoca, ktera obsahuje data z .desktop souboru a podobne. Kdyby neexistovala, hodne operaci by potrebovalo prohledani velkeho mnozstvi .desktop souboru a to dlouho trva. Jak uz bylo receno, pri cteni hodne malych souboru rapidne klesa vykon. Ackoliv hodne dnesnich disku zvladne 50MB/s v blokovem prenosu, jen maloktery ma prumernou pristupovou dobu pod 10ms. S troskou matematiky je snadno spocitat, ze takovy disk tedy za sekundu precte tak mozna 100 souboru. To je zoufale malo a kernelovi vyvojari teprve ted se pomalu zacinaji snazit s tim neco delat (asi to bude chtit neco ve stylu lepsiho usporadani data na disku a cteni vetsiho mnozstvi data naraz). KSycoca tenhle problem resi tim, ze vsechny udaje z .desktop souboru obsahuje, jenze pri startu KDE je potreba udelat kontrolu, ze se .desktop soubory nezmenily - je potreba na vsechny sahnout. Potom za behu KDE uz jeden daemon hlida zmeny a vsechno je v poradku, jenze pri pouzivani KDE aplikaci mimo KDE , pokud zadna KDE aplikace neni aktivni, tenhle daemon nebezi - kontrolu je potreba udelat pokazde.
• Kdyz se spusti KDE aplikace mimo KDE, tak se samozrejme KDE knihovny nahraji a aplikace si spusti i zakladni KDE daemony (protoze je zkratka potrebuje). Jenze jakmile se takova KDE aplikace ukonci, po malem zpozdeni se kompletni podpora pro KDE ukonci taky a pri dalsim startu se nahravani musi opakovat. Je to tak schvalne, nikomu by se asi nelibilo, kdyby jinak takovehle veci na pozadi zablokovaly treba odhlaseni z ssh -X. Jenze v pripade spousteni KDE aplikaci v jinem prostedi to je samozrejme problem.

Neni pak divu, ze start i te nejmensi KDE aplikace mimo KDE dokaze trvat vecnost. Kazdopadne, da se s tim par veci delat:

• Modlit se denne k Velkemu Tuxovi (jeho jmeno budiz pochvaleno!), at uz konecne v glibc a v kernelu pro tyhle veci existuje slusna podpora. Varianta s dlouhodobym casovym horizontem, mam obavy.
• Vypnout kontrolu konzistence KSycoca. Resp. spis ji pozdrzet, provede se asi s minutovym zpozdenim. Tim se vyrazne usetri cteni z disku a start muze byt znatelne rychlejsi. Pokud se .desktop soubory nemeni, nic se nedeje, a .desktop soubory se povetsinou nemeni, jen pri instalacich a podobne. Pokud se zmeni, maximalne se behem te prvni minuty nektere zmeny neprojevi (coz muze zpusobit v extremnim pripade treba i nefunkcnost aplikace, kdyz nenajde svuj zakladni mime typ a rozhodne s necim takovym nepocita - proc taky). Prepinac ovlivnujici tohle nastaveni je v ovladacim modulu Vykon KDE (jde primo spustit jako kcmshell kcmperformance), zalozka System. V pripade problemu staci provest rucni kontrolu prikazem kbuildsycoca.
• Pouzit prelink. Ackoliv jsem nahore napsal, ze to rozhodne v soucasne dobe neni zadny zazracny nastroj, rozhodne porad pomuze. A, ackoliv se to obecne tvrdi, je otazka, jestli je dobry napad nastavit i $KDE_IS_PRELINKED na 1. Ja osobne bych to nedelal (a to plati i pro pouzivani KDE, ne jen pro pouzivani KDE aplikaci mimo KDE).
• Nahrat rucne uplne zakladni podporu KDE. Pak budou nahrane KDE knihovny, ld.so provede svoji pomalou praci jen jednou, daemon hlidajici zmeny .desktop souboru bude porad aktivni. Usetri se tim skoro vsechna prace potrebna pri startu KDE aplikace mimo KDE, resp. provede se jen jednou. Navic, i pres tvrzeni nekterych lidi, to vubec neni takova katastrofa jak by se mohlo zdat. V pameti pribude hrstka KDE daemonu, jenze ty skoro nic nezabiraji (a kdo se chce hadat, at me nejdriv presvedci, ze rozumi mereni spotreby pameti na Linuxu) a jejich samotny start je dilem okamziku. Pak jsou v pameti jeste samozrejme knihovny KDE, jenze ty pri nepouzivani budou drive nebo pozdeji skoro cele vyhozene z pameti a v pripade potreby nactene znovu - akorat tentokrat uz bez ld.so a podobnych zdrzovani. Jednoduche reseni je do prislusneho startovaciho skriptu (~/.xinitrc nebo kdo co pouziva) napsat kdeinit. Tak se behem startu nahraji i KDE knihovny a zakladni daemony. Problem tady je trochu ten, ze tak si clovek posune startovaci cas sveho oblibeneho grafickeho prostredi XYZ [zde prosim doplnit] k startovacimu casu KDE a pak uz by mozna stalo za to i zvazit primo pouzivani KDE :). Nebo se zamyslet a zkusit neco ve stylu ionice, sleep atd. (mimochodem, podminene spusteni kdeinit jen pokud uz nebezi se udela jako dcop >/dev/null 2>/dev/null || kdeinit).

Takze asi tak ...

       

Komentáře

[Luk]

Jsem rád, že to tu zaznělo. Někteří lidé mají pořád tendenci házet na KDE špínu, i když nevědí, jak se věci mají. Snad ti to přečtou a budou moudřejší

[andree]

tomu ver ze tu taki budu Na druhej strane treba povedat, ze KDE je obcas dost pomale. Ja to ale s radostou vymenim za tie schopnosti a previazanost komponentov. KDE je krasne prostredie, rychlost sa predsa doriesi (staci prechod z hdd na flash-like media, ked nebude zalezat od druhu pristupu - sekvencny/random)..

[andree]

a zabudol som - pekny clanok

[Heron]

Pěkný článek.

Připomněl mi jabber hádku s jedním linuxářem, který posuzoval kvalitu programu podle délky jeho spouštění. To je samo o sobě kravina. Nebudu tu uvádět jeho jméno, ani programy o které se jednalo, protože by to byl jen námět na další flame.

Nejde ani tak o rychlost startu ani okamžité hodnoty spotřeby paměti (což některým stačí jako argumenty pro/proti), jde o trendy. Jak dlouho trvá následná operace, kdy už jsou všechny knihovny načteny v cache a jsou spočítány adresní prostory? Jak to vypadá se stabilitou v čase? V tomto udělalo KDE velký krok dopředu. Spotřeba paměti s časem příliš neroste, poslední verse (KDE 3.5.4) má zřejmě opravené memory leaky, které mě trápili dřív. Jen tak dál.

[xxxxxxxx]

to s tim kdeinit je good idea, diky moc'

[xy]

mne sa OpenOffice.org prelinkne

[Luboš Luňák]

Kdepak. Prelinkne se soffice.bin, jenze to neni OpenOffice.org, to je mala binarka. Zbytek jede pres dlopen a to prelink neumi -> smula. Mohl by to umet, s pouzitim stejneho principu jako -Bdirect, ale kdyz se nelibi -Bdirect, nelibil by se asi ani tenhle pristup v prelinku :(.

[Josef Kufner]

Právě jsem upgradoval počítač z KDE 3.3 na KDE 3.5 (mimojiné) a při té příležitosti trošku doladil konfiguraci. Tak nějak jsem došel k tomu, že to je poněkud molochovité, chová se to tak nějak všelijak, stále to má debilní dialog na výběr barvy (Gtk je na tom v tomhle směru hůř s file dialogy) a je to na mě moc líné, ale mohlo by být hůř. Naštěstí to není můj desktop – můj je plný xtermů ve fullscreenu a mezitím občas něco v gtk (ne gnome).

Hlavně mě dostává doba startu KDM. Je to něco děsnýho. XDM startuje kolem 1 sec, kdežto KDM asi 20 sec, což se při startu Xek nějakých 30 sec po zapnutí počítače celkem protáhne.

Malý hint na zkrácení doby bootu: mv /etc/rc2.d/S99kdm /etc/rc2.d/S10kdm -- sice to boot vlastně nezkrátí, ale aspoň to neotravuje a co na tom, že se nějaký ptákoviny nespustí ještě před přihlášením

[Mark]

Takže plný xtermů ve fullscreenu?

konsole vs xterm

Psst...

[disorder]

to je sice krasne, ale AFAIK rxvt dokaze viac tabov (alebo nejaky jeho klon?). a xfce4-terminal sa forkuje (taby nepouzivam), ma funkcie co pozadujem a nevyzaduje KDE :P

[andree]

ale vyzaduje gtk - so what? :-P

[stativ]

ten klon se jmenuje mrxvt, BTW skvelej terminal (ma i vyhlazovani pisma a pruhlednost). A nespotrebuje o nic vic pameti nez rxvt.

[Josef Kufner]

To je sice hezké, že nový tab si veme jen pár kilo, ale celá instance si veme 17 MB, takže tím to bohatě vynahradí. Kdeto aterm, který momentálně používám (mám v ~/bin symlink který se jmenuje xterm), si veme s každou instancí necelé 2 MB. Což znamená, že bych musel otevřít více než 8 tabů v každe instanci konsole, aby se mi to vyplatilo. Ale protože používám 32 ploch, tak taková situace nastane jen výjimečně – obvykle mám otevřeno na jedné ploše maximálně tak 5 terminálů, průměrně zhruba 3.

Co se týče rychlosti, tak konsole taky není moc rychlá... výpis slovníku american-english (98569 řádek) zabral atermu 1,17 sec a konsoli 6,1 sec při stejném fontu (Terminus) a velikosti (80x25). Měřeno několikrát.

[disorder]

to je fajn takto pausalne odsudit file dialog. je tak tazke pochopit, ze niekomu vyhovuje viac nez ten windowsacky?

[Michal Kubeček]

Proč paušálně? My odsuzujeme jeden konkrétní - tedy přesněji dva, ale ony jsou si dost podobné. Jinak je problém spíš v tom, že pro autory Gtk je těžké pochopit, že i když oni ten svůj výtvor považují za vrchol dokonalosti a pohodnosti používání, nemalá část uživatelů ho hodnotí úplně jinak…

[disorder]

"Gtk je na tom v tomhle směru hůř s file dialogy"

tam nie je priestor pre ludi, ktorym to je jedno alebo to vidia opacne.

"pro autory Gtk je těžké pochopit, že i když oni ten svůj výtvor považují za vrchol dokonalosti a pohodnosti používání, nemalá část uživatelů ho hodnotí úplně jinak"

vsak uz mi bolo mnohokrat povedane, ze si clovek vystaci len s KDE aplikaciami, tak heš ked sa nelubi

[Michal Vyskočil]

Možná to pro tebe bude těžké si představit, ale ne každý si vybírá aplikace podle toolkitu, v němž jsou napsané, ale podle toho, jak mu vyhovují. Je pravda, že uživatelé KDE preferují spíše K aplikace, ale neplatí to 100%. Nevidím jediný důvod, proč v klidu nepoužívat kvalitní Gtk aplikaci, jakou je třeba gvim a nevolal všude po qvimu v Qt.

Mimochodem Bram je asi taky strašný Windowsák, protože gvim (alespoň ve verzi 6.4) nemá klasické gtk2 open/save dialogy, což je bohužel situace, ze které nemám radost vůbec (pokud si bude každý autor gtk programů psát vlastní file dialogy, bude to ještě horší, než je to teď). Ale co, hlavně, že jsou ty gtk dialogy tak slvěle intuitivní.

BTW: zrovna u gvimu je mi to jedno, používám :set guioptions=

[disorder]

akoze ja som voci file dialogom apaticky. co na mna vybafne, to pouzijem (ale preferujem Gtk). to vy vsetci tak casto pouzivate? nedokazem pochopit, ze je to taky problem (alebo ste neprisli na ine "slabe miesto" Gtk?)

[Michal Vyskočil]

Tak, až přijdeš na to, jak se v tom standardním dostat z /někde/01/něco/jiného do /někde/02/něco/jiného stejně rychle, jako u kteréhokoliv jiného dialogu s cestou, budu moc rád . Navíc nerozumím, proč je ten dialog tak obrovský, když zobrazuje daleko méně věcí, než ostatní, ale to už je maličkost.

Slabé místo Gtk je například v rychlosti, ale u té věřím, že se časem provede optimalizace (hlavně cairo to potřebuje jako sůl). Ovšem já nepotřebuji hledat slabá místa, já toolkity neřeším. Jediné, co mi vadí je ten open/save dialog, protože se mi v něm jednoduché operace zaberou více operací, než jinde. Mít možnost používat jiný (klidně i ten z gtk 1), neřeknu ani popel .

[disorder]

to nepotrebujem. tak casto to nepouzivam a obmedzujem sa na ~/ so zmysluplnou strukturou (a teda je pre mna rychlejsie stlacit zaciatocnu klavesu a enter).

[Jiří (BoodOk) Kadeřávek]

Ja mam doma taky poradek, ale travim tam jen pul dne. Zbytek dne se pohybuji mimo a v takovem pripade je mi poradek doma k nicemu.

[nhy]

Na hnusne Gtk dialogy je tu riesenie s menom KGtk. A hned je svet krajsi

[Bubak]

No jo, nelubi, nepouzivaj. Jenze kdyz mi ho nacpali do Firefoxu ... Klikat na nejaky nesmyslny widget, abych teprve zobrazil list adresaru a souboru, fakt me to vytocilo. Nevim, treba se to da nastavit, treba se Firefoxu da rict, ze ma pouzivat neco jineho, neresil jsem to, to vis, lenost. Ale pripadaji mi ta defaultni nastaveni cim dal debilnejsi. (Ale to nejen u Gtk. Defaultni nastaveni KDE take miluju. Ale to pouzivam casteji, takze si pohraju s tim, abych vypnul vsechny nesmyslnosti - z meho pohledu, samozrejme.)

[disorder]

opera

[JardaK]

A co třeba tento Firefox?

[Michal Kubeček]

Dobrá zpráva: ve Firefoxu lze používat nativní dialog z KDE a není to ani moc složité. Jen se o tom bohužel moc neví, ten odkaz jsem objevil víceméně náhodou v diskusi pod jedním článkem na Rootu. Mimochodem, v tom článku je další skvělý trik - popis, jak ve Firefoxu 2.0 zachovat tradiční jedno tlačítko pro zavření tabu.

[VícNežNic]

Řečí tisíce, ale ještě jsem neviděl byť jediný návrh lepšího fileselectoru (nebo něco takového jako zkusit to dokonce v GTK+ dohackovat).

[Michal Kubeček]

Já jsem filepicker, se kterým se mi pracuje lépe, viděl - např. ten v KDE, ale i spousta dalších. Horší (pro mne) býval snad jen ten, který se vyskytoval před deseti lety v xdvi.

[VícNežNic]

Tady bude asi ten problém, že já si naproti tomu zase větší hrůzu než to z KDE už moc představit nedovedu.

[Petr Bayer]

jj

[andree]

O RLY? ;o) a dovody?

[MJ]

Zrovna u toho GTK-čkového dialogu je spíše velké umění hodit si uspořádání dialogu kostkou a přijít s něčím horším

Upřímně – dialog, do kterého se nedá přímo napsat jméno souboru, je nanic.

[disorder]

akoze neda? hore mas kolonku Name a v suborovom systeme mas incremental search. staci slacat klavesy.

[Kníže Ignor]

Machrovat se musí umět a taky je potřeba vědět před kým machruješ

[disorder]

ja ocakavam odpoved. lebo som akosi nepochopil coze sa neda a uviedol som co sa da. co je na tom?

[Josef Kufner]

Já takový dialog viděl. Byl v Gtk 1 a chvíli v Gtk 2. Když by se mu přidalo pár fičurek (třeba záložky) a trošku poladily operace se soubory, tak by to bylo téměř dokonalé.

[Daniel Kvasnička ml.]

Jinak je problém spíš v tom, že pro autory Gtk je těžké pochopit, že i když oni ten svůj výtvor považují za vrchol dokonalosti a pohodnosti používání, nemalá část uživatelů ho hodnotí úplně jinak…

Tezke pochopit? Ja myslim, ze to chapu dobre, akorat je jim to fuk, protoze maji svoji cilovou skupinu "zakazniku" a te to vyhovuje.

[Luboš Luňák]

Slo by prosim tohle opakovane, nekonecne a nic neresici hadani se o file dialog prestehovat nekam jinam? Moc diky.

[Luboš Luňák]

Hlavně mě dostává doba startu KDM. Je to něco děsnýho.

Co na to rict? Pomale nahravani knihoven. Navic pri bootu se souperi o pristup na disk s ostatnimi spoustenymi sluzbami (treba CUPS ma podobny problem pri startu jako ma ksycoca), takze je to jeste znatelne horsi.

[disorder]

na co sluzi ten zahadny subor .desktop?

aj by som si to vygooglil, ale az tak ma to nezaujima...

[David Watzke]

Ikony... je v tom napsáno co má ikona dělat, jak se má jmenovat, cesta k obrázku, MIME typy, který má handlovat...

[VícNežNic]

Ikona?

[Luboš Luňák]

Tim jsou asi mysleny polozky v menu aplikaci (K-Menu) - .desktop soubory obsahuji popis aplikace (jmeno, ikona, jake druhy souboru umi otevrit, atd.), navic v KDE se jeste pouzivaji treba i na popis komponent KParts, takze jich mame stovky.

[David Watzke]

Ano. I ikony na ploše...

[Mark]

No ked ta to az tak nezaujima, tak ti nenapisem, na co sluzi ten zahadny subor .desktop.

[Kníže Ignor]

Omluvte prostý dotaz dokonalého dřeváka, ale proč se ta cache toho démona KSyscoca před jeho ukončením neodloží v nějaké formě na disk do jednoho souboru a při příštím startu se znovu nenačte a zkontroluje se pouze, zda se nějaký ten .desktop soubor nezměnil? Taková kontrola by se mohl spoléhat třeba na datum změny, případně by se ještě projistotu mohla kontrolovat velikost toho souboru, ale soubor samotný by se načítat nemusel.

[Luboš Luňák]

Trochu spatne jsem to vysvetlil. Ksycoca je soubor (ktery obsahuje data pripravena ze vsech .desktop souboru). Samotne .desktop soubory se normalne vubec nepouzivaji, problem je prave ta kontrola. I jen datum zmeny porad znamena cteni z disku, .desktop souboru jsou stovky a protoze to znamena seekovani, je to hodne pomale. A zadny jeden globalni datum zmeny cele adresarove struktury neexistuje, kernelovi vyvojari se nejdriv dlouze tvarili nechapave a kdyz jim to konecne doslo, tak potom odmitave. Takze to ted pise jako systemoveho demona, snad uz to bude prakticky pouzitelne pro KDE3.5.6. Zatim je tu jen ta popsana moznost tu kontrolu vypnout.

[MJ]

Pěkný rozbor, ale nevím nevím, jestli mu opravdu věřím... Se spoustou tvrzení by se dalo polemizovat, ovšem místo toho nechám raději hovořit jednoduchý experiment:

Rxvt se na mém stroji spustí na odklepnutí, kdežto Konsole nabíhá něco okolo půl sekundy, i když všichni kde-čkoví daemonci ještě běží a všechny soubory jsou nacacheované. To prostě rychlé není a nevěřím, že se všechen ten čas tráví v dynamickém linkeru (hint: třeba takový graphicsmagick, který nepoužívá o moc knihoven méně, se spustí mnohem rychleji).

Ostatně, co se linkeru týče, velmi doporučuji článek How to Write Shared Libraries od Ulricha Dreppera.

[Luboš Luňák]

Ten priklad sice neni zrovna tenhle pripad, ale napsal jsem "moc za to nemuzeme". Jisteze urcita cast startu se travi i v kodu KDE, jinak to nejde. Obzvlast kdyz kod KDE knihoven je na rozdil od kodu rxvt obecny a dela toho daleko vic (hint: graphicsmagick nejspis nepouziva tak rozsahle knihovny jako kdelibs).

Kdo si mysli, ze vyvojari KDE jsou amateri, kteri neumi programovat, a ze on by to dokazal v pohode napsat rychleji, je vic nez vitan to zkusit. Slibuju, ze se nebudu smat, kdyz to nakonec moc nepujde.

Co se tyka toho dokumentu od Ulricha Dreppera, ten samozrejme znam. Z technickeho hlediska zajimavy, ale taky ukazuje, ze lide pracujici na nizkourovnovych vecech jako kernel nebo glibc nemaji moc poneti, jak vlastne pracuji veci, ktere je pouzivaji. Nektere ty rady, jak rucne vylepsit knihovny, aby to bylo rychlejsi, jsou dost smesne (uz vidim, jak rucne prepisuju vsechny tridy v kdelibs kvuli drobnemu zrychleni). A nebo treba strana 7, pravy sloupec: Pred gcc-3.0 se C++ identifikatory kodovaly jako symboly tak, ze nejdriv slo jmeno metody a az potom jmeno tridy - porovnani symbolu ze stejnych trid bylo rychle, protoze zacatky se lisily. Ted se pouziva novy format, kde je to "hezky" v poradi, ale funguje to pomalu, protoze symboly maji dlouhe stejne zacatky. Je to chyba noveho formatu? Neeeee, je to chyba C++ (Ady, programatoru snazicich se psat strukturovany kod, doplnte cokoliv). Jak se potom ma s nimi clovek bavit :( ? Se nedivim, ze Michal Meeks nemuze Drepperovi prijit na jmeno.

[MJ]

Jisteze urcita cast startu se travi i v kodu KDE, jinak to nejde. Obzvlast kdyz kod KDE knihoven je na rozdil od kodu rxvt obecny a dela toho daleko vic[...]

No jo, ale jak rxvt ukazuje, většina toho, co dělá KDE při té své inicializaci knihoven, je milé Konsoli úplně nanic a jen zdržuje. Jistě že napsat to tak, aby se vždy inicializovalo všechno, je daleko jednodušší, ale pak se autoři nesmí divit, že jim lidé nadávají, že je to ukrutně pomalé. (Hint: toto není filipika proti KDE, spíš obecně proti mentalitě tvůrců desktopových prostředí.)

Kdo si mysli, ze vyvojari KDE jsou amateri, kteri neumi programovat, a ze on by to dokazal v pohode napsat rychleji, je vic nez vitan to zkusit.

Když oni ti, kteří by možná uměli, se raději spokojí s rxvt, jelikož to stejně všechno, co potřebují, dokáže

Co se tyka toho dokumentu od Ulricha Dreppera, ten samozrejme znam. Z technickeho hlediska zajimavy, ale taky ukazuje, ze lide pracujici na nizkourovnovych vecech jako kernel nebo glibc nemaji moc poneti, jak vlastne pracuji veci, ktere je pouzivaji.

Věřím, že to ponětí mají, jen s C++-kovým ABI se bohužel nic moc nadělat nedá – příšerně dlouhá jména a hromady relokací se sotva dají linkovat efektivně. Neříkám, že by to nemohlo být rychlejší, ale rychlé určitě ne. Ať se na to dívám z kterékoliv strany, vždy mi vychází, že to opravdu je chyba C++ a že by naopak autoři ABI měli víc přemýšlet nad tím, jakou režii která konstrukce má.

Ostatně, když za všechno může dynamický linker, proč si KDEčkáři nenapíší vlastní? Proti rozsahu celého KDE maličkost ;)

[Luboš Luňák]

No jo, ale jak rxvt ukazuje, většina toho, co dělá KDE při té své inicializaci knihoven, je milé Konsoli úplně nanic a jen zdržuje. Jistě že napsat to tak, aby se vždy inicializovalo všechno, je daleko jednodušší, ale pak se autoři nesmí divit, že jim lidé nadávají, že je to ukrutně pomalé. (Hint: toto není filipika proti KDE, spíš obecně proti mentalitě tvůrců desktopových prostředí.)

Soucasti inicializace Konsole v ramci kodu knihoven je nahrani stylu widgetu, inicializace fontu (fontconfig+xft, aby to umelo janevimco), nahrani ikon, vytvoreni menu, atd. Ok, tohle mozna terminal striktne vzato nepotrebuje, pro takove lidi tu je xterm/rxvt a podobne, jenze co se s tim ma jakoze delat v pripade Konsole?

• Vsechny ty inicializace povypinat? To bude jednak maso udelat, jednak, jak ma potom Konsole nakreslit vpravo scrollbar, jak ma nakreslit menu, jak ma vypisovat fonty? Nehlede na to, ze vetsina uzivatelu veci jako styly widgetu, antialiasovane fonty a podobne chce, at uz se to nekomu libi nebo ne.
• Napsat si na to kod zvlast? A jaky by byl potom smysl kdelibs, kdyz by si stejne kazdy ten kod napsal zvlast?
• "Optimalizovat" (tj. osekat, samozrejme, ne doopravdy optimalizovat) kod v kdelibs tak, at je to rychlejsi? A co potom flexibilita, jakou clovek potrebuje od knihoven? A co treba rychlost vyvoje aplikaci? Pro KDE byly napsany stovky a stovky aplikaci, vcetne WWW browseru a office baliku s obvykle daleko mensim poctem vyvojaru nez i jinych obdobnych aplikaci, to se ma najednou vsem tem vyvojarum misto ulehcovani zivot najednou komplikovat? Nekdo, kdo si kuchti vlastni aplikaci odspodu az nahoru tenhle problem nema, ale nas proste neco stoji. At se tomu rika treba mentalita, ale treba cas a vyvojari taky nerostou jen tak na stromech.

Kdo si mysli, ze vyvojari KDE jsou amateri, kteri neumi programovat, a ze on by to dokazal v pohode napsat rychleji, je vic nez vitan to zkusit.

Když oni ti, kteří by možná uměli, se raději spokojí s rxvt, jelikož to stejně všechno, co potřebují, dokáže

Zvlastni, jak z te citace tak nejak zahadne vypadla ta cast o tom, ze to ma hodne hodne daleko k tomu byt jednoducha zalezitost :).

Ostatně, když za všechno může dynamický linker, proč si KDEčkáři nenapíší vlastní? Proti rozsahu celého KDE maličkost ;)

No my jsme si ho samozrejme tak trochu napsali, rikame mu kdeinit :). Akorat jsme si naivne mysleli, ze to ti, kdo by to spravit meli, zvladnou i rychleji nez za sto let, takze po kdeinitu jsme sli zase pracovat na tom, na cem jsme puvodne chteli pracovat, na desktopu. Vzhledem k ostatnim nutnym zalezitostem se planujeme k tomuhle problemu vratit v roce 2023, pokud nejakym omylem to mezitim uz neudelaji v glibc ;).

[MJ]

Soucasti inicializace Konsole v ramci kodu knihoven je nahrani stylu widgetu, inicializace fontu (fontconfig+xft, aby to umelo janevimco), nahrani ikon, vytvoreni menu, atd.

Opravdu se mi nechce věřit, že na tyhle v podstatě jednoduché záležitosti je potřeba řádově několik miliard strojových instrukcí.

Napsat si na to kod zvlast? A jaky by byl potom smysl kdelibs, kdyz by si stejne kazdy ten kod napsal zvlast?

Ne, ale například by aplikace mohla dopředu knihovně napovědět, co bude potřebovat, aby se nemuselo zbytečně inicializovat všechno.

"Optimalizovat" (tj. osekat, samozrejme, ne doopravdy optimalizovat) kod v kdelibs tak, at je to rychlejsi? A co potom flexibilita, jakou clovek potrebuje od knihoven?

Viz výše.

A co treba rychlost vyvoje aplikaci?

To je konečně argument, který dává smysl. Pokud je cílem KDE psát aplikace rychle a nikoliv rychlé, skládám své zbraně a odcházím z kolbiště :)

No my jsme si ho samozrejme tak trochu napsali, rikame mu kdeinit :).

Ehm, kdeinit má opravdu k dynamickému linkeru daleko, je to spíš obludný hack, který se snaží všemu dynamickému linkování vyhnout. Takže to opravdu stále nevypadá, že by někdo ukázal, jak lze C++ linkovat rozumně.

[Luboš Luňák]

Opravdu se mi nechce věřit, že na tyhle v podstatě jednoduché záležitosti je potřeba řádově několik miliard strojových instrukcí.

Prekvapeni, ze jo :( ? Vetsina veci pri startu je vlastne strasne rychla, jen se jich dela moc a ono se to nasklada. Navic hodne z toho jsou inicializace knihoven, ktere KDE pouziva, a s tim se potom dela neco daleko hur (treba jednu dobu inicializace fontconfigu byla az 1/3 startu KDE aplikace).

Ne, ale například by aplikace mohla dopředu knihovně napovědět, co bude potřebovat, aby se nemuselo zbytečně inicializovat všechno.

Patche jsou vitany ... kdyby to byla takova trivka, uz bych to davno udelal. Pro ty veci, kde je to jednoduche, se to uz samozrejme davno dela. My se ve skutecnosti i docela dost snazime to napsat tak, aby to bylo rychle, s tim, jak nam to zhorsuji veci, na ktere mame maly vliv a s tim, jak se nam to kazdy snazi omlatit o hlavu, proste musime.

Pokud je cílem KDE psát aplikace rychle a nikoliv rychlé, skládám své zbraně a odcházím z kolbiště :)

Ekonomove udajne maji poucku, ktere rikaji Pravidlo Tri. Ty tri jsou (pokud si dobre vzpominam) penize, kvalita a cas (nez se produkt dokonci). Samotna poucka rika, ze se maji vybrat jen dve z nich, protoze vsechny tri mit nejde (kvalita stoji cas a penize, kratsi cas stoji penize a snizenou kvalitu, penize se usetri horsi kvalitou a bude to dele trvat).

Podobne pravidlo se da udelat i tady, kde ty tri budou cas (=program nebude jako Hurd), kvalita (=program nebude jako Windows95) a rychlost (=program nebude jako ... er :) ). No a co si ted vybrat? Program, ktery nebude jeste hotovy, kdyz ho bude clovek potrebovat, program, ktery nebude vlastne fungovat, nebo program, ktery bude existovat, bude delat, co se od nej chce a bude jen pomaly?

Takže to opravdu stále nevypadá, že by někdo ukázal, jak lze C++ linkovat rozumně.

Jisteze by to slo. Staci treba umyslne porusit to povetsinou zbytecne pravidlo, ktere -Bdirect porusuje, a je to :).

[Non_E]

To není (jen?) pravidlo ekonomů, to je článek 7 rfc 1925, jak o něm už na ábíčku psali.

[MJ]

Prekvapeni, ze jo :( ? Vetsina veci pri startu je vlastne strasne rychla, jen se jich dela moc a ono se to nasklada.

Stokrát nic sice umořilo osla, ale kdyby tohle byla samá nic, musely by jich být miliony. Spíš bych řekl, že u většiny těch věcí si nikdo moc nelámal hlavu, jak rychlé jsou, protože jsou přeci jednoduché, a ono se to pak naskládalo...

Navic hodne z toho jsou inicializace knihoven, ktere KDE pouziva, a s tim se potom dela neco daleko hur (treba jednu dobu inicializace fontconfigu byla az 1/3 startu KDE aplikace).

Zrovna fontconfig je udělaný tak šíleně, že je skoro svatou povinností autora desktopového prostředí ho přepsat ;)

[...] nebo program, ktery bude existovat, bude delat, co se od nej chce a bude jen pomaly?

To je tak trochu protimluv – aby byl program použitelně (či ještě lépe příjemně) rychlý, je přeci součást toho, co se od něj chce.

Jisteze by to slo. Staci treba umyslne porusit to povetsinou zbytecne pravidlo, ktere -Bdirect porusuje, a je to :).

Nesouhlasím, -Bdirect vyřeší pouze zlomek všech problémů. Pokud knihovna obsahuje desítky tisíc příšerně dlouhých symbolů a srovnatelný počet relokací, bude se sotva linkovat rychle. Přitom značná část těch symbolů nejspíš vůbec nepotřebuje být zvenku viditelná a většiny relokací by se také šlo zbavit.

Ale to už jsme trochu odbočili, ona se stejně většina času netráví v dynamickém linkeru. Zkusil jsem si teď strace na Konsoli a překvapilo mne, že při startu provede 5721 syscallů, z čehož například několik stovek se zabývá úplně zbytečným prohledáváním všech možných i nemožných adresářů v /usr/share/icons ... to zrovna nevypadá na věci, které je při startu nezbytné udělat.

[Non_E]

Zkusil jsem si teď strace na Konsoli a překvapilo mne, že při startu provede 5721 syscallů, z čehož například několik stovek se zabývá úplně zbytečným prohledáváním všech možných i nemožných adresářů v /usr/share/icons ... to zrovna nevypadá na věci, které je při startu nezbytné udělat.

Zvláštní, že mně strace -c konsole dává jen 1008 syscallů.

[Luboš Luňák]

To je tak trochu protimluv – aby byl program použitelně (či ještě lépe příjemně) rychlý, je přeci součást toho, co se od něj chce.

"Samotna poucka rika, ze se maji vybrat jen dve z nich, protoze vsechny tri mit nejde".

A vubec, kdyz je to tedy vsechno takova trivka, co si usetrit cas a misto tohohle povidani mi zkratka rovnou poslat ty patche? Ja uz se pak o ne postaram a slibuju, ze nezapomeneme na pametni tabuli.

[MJ]

"Samotna poucka rika, ze se maji vybrat jen dve z nich, protoze vsechny tri mit nejde".

Jenže ta poučka hovoří o čase potřebném na vývoj, ne o rychlosti výsledku, není-liž pravda?

A vubec, kdyz je to tedy vsechno takova trivka, co si usetrit cas a misto tohohle povidani mi zkratka rovnou poslat ty patche?

Rád bych, ale tohle bohužel není na pár patchů, nýbrž na dosti zásadní redesign. Asi raději zůstanu u toho rxvt a podobných starých dobrých aplikací

[Deleted [8409]]

Fontconfig je brzda všeho, stačí udělat prográmek který ho zinicializuje a zase hned uvolní, mi trvá několikáté zpuštění asi 0.3s na Athlon 1800+ (což je hodně dlouho)

Ale rád bych se Vás zeptal co by se stalo, kdybych aplikaci nelinkoval k Xlib a obecně Xlib knihovnám, ale kdybych si je otevřel přes dlopen, bylo by to rychlejší (myslím čistě aplikaci pod X) ? Něco jsem na ten způsob udělal ale nepoznám jestli je to rychlejší, aplikace se zobrazí prostě hned

[Luboš Luňák]

Fontconfig-2.3.9x se uz chova rozumneji, co se tyka rychlosti (i za jiste pomoci jistych KDE vyvojaru).

Dynamickou knihovnu linkovat nebo otevirat pres dlopen je technicky skoro to same, ld.so vicemene na zacatku dela "dlopen" vsech linkovanych knihoven.

[Non_E]

Pěkný článek. Sice jsem čekal spíš rady jak s kde aplikacemi v kde desktopu, ale i tak bylo zajímavé se něco dočíst. Hrál jsem si s -Bdirect (prý porušuje standardy elf binárek, ale v tom se nevyznám) a teď mám skoro všude DT_GNU_HASH s prelinkem a jsem spokojený.

[Luboš Luňák]

-Bdirect (umyslne a volitelne) porusuje jedno pravidlo o vyhledavani symbolu v knihovnach, protoze to pravidlo hrozne zdrzuje, v tak asi 99,9%[*] pripadu neni potreba a v 0,01% pripadu jeste navic dela jen problemy. Kdyz se navrhoval ELF standard, tak se snazili, at se sdilene knihovny chovaji stejne staticke a odsud to divne pravidlo pochazi. Se stejnym pristupem jako -Bdirect by mohl dobre fungovat i prelink na dlopen (tj. fungoval by treba s OpenOffice.org). Jen by to samozrejme nekdo musel dostat pres Dreppera.

[*] 85,73% vsech statistik jsou samozrejme nesmysly.

[Bubak]

Myslim, ze tohle by melo vyjit spis jako clanek, nez jen takhle v blogu ... Jak psal xkesh, lehce se to tu ztrati a zapomene. A pritom je to velice uzitecne.

Co mi brani zavolat v .xinitrc kdeinit na pozadi? Tak bych to vpodstate nemel vubec poznat, ne?

[Luboš Luňák]

Co mi brani zavolat v .xinitrc kdeinit na pozadi? Tak bych to vpodstate nemel vubec poznat, ne?

Nooo ... ja pravdu rict si nejsem uplne jisty, jak se bude chovat kdeinit pri vice soucasnych spustenich (ja KDE samozrejme pouzivam, takze tuhle fintu vlastne nepotrebuju). Mam takove podezreni, ze by obcas mohly byt drobne problemky.

Pokud je zaruceno, ze pred timhle rucnim spustenim kdeinit se zadna KDE aplikace nepusti (treba session management toho prislusneho prostredi), tak by mohlo fungovat i "kdeinit &". Jenze i takhle to stejne muze zdrzet start toho prislusneho prostredi. Kdyz se tam da neco ve stylu "sleep 20; kdeinit" (nebo i vcetne toho testu, jak jsem napsal nahore), tak kdyz se driv spusti KDE aplikace, tak ta uz kdeinit spusti, jenze docasne -> po jejim skonceni se ukonci i kdeinit a rucni spusteni fungovat nebude, protoze kdeinit uz bezi :-/.

Kdyz tak nad tim premyslim, mozna by sla udelat volba na vypnuti automatickeho ukoncovani kdeinit. Pak by trval dlouho prvni start nejake KDE aplikace, ale dalsi uz by byly v poradku, protoze kdeinit by zustal viset v pameti. Akorat tohle je reseno tak hluboko, ze tam vlastne jeste na veci jako konfiguracni volby nejde pristupovat :-/. Mozna promenna shellu ... ok, kolik by za neco takoveho asi mohlo byt dekovnych dopisu s prilozenou cokoladou ;) ?

[peter_h]

A preco to vlastne nemoze fungovat na 100% ako pri DLLkach? Tie su vlastne prelinkovane vsetky. Ale toto nie je len o linkeri, isteho casu som mal prelinkovane KDE, ale aj tak to dlho startovalo. Napr. ta ksyscoca, nemoze mat zoznam nacachovanych suborov a potom vyvolat nejaky asynchronny call na stav tych suborov? Nech si to uz jadro nejako usporiada (ci takuto jednoduchu vec kernel nevie?). Neviem ako funguju tie preloadery (aj v suse je tusim taky), ale malo by to fungovat podobne (proste aby bolo to citanie sekvencne).
Dalsia vec co nechapem, preco musim mat v .desktop a inych suboroch milion kadejakych jazykov, neexistuje na to nejaky nastroj, ktory vyselektuje len tie, ktore ja chcem?
Pokial to nebude startovat ako blender (tj instantne), tak budu vzdy existovat ludia, ktori sa budu stazovat na rychlost. Ono totiz dost stve, ked clovek prebootuje z windowsov a zrazu akoby sa mu spomalil pocitac. Alebo zmena velkosti okna - ten gumi efekt fakt nie je zaujimavy (to nemam na mysli compiz).

Teraz trochu offtopic - prave som cital v maili to blokove citanie x properties - nemate nejake konkretne cisla? Dost by ma zaujimalo, kolko casu zaberie komunikacia QT/KDE s xserverom pri starte aplikacie.

[Luboš Luňák]

A preco to vlastne nemoze fungovat na 100% ako pri DLLkach? Tie su vlastne prelinkovane vsetky.

Rekl bych, ze setrvacnost (tedy krom toho, ze na Windows je vsechno totalne spatne, ELF je prece skvely a tak). Pred deseti lety by se dnesni stav s binarkami pouzivajici treba i sto sdilenych knihoven asi povazoval za silenost - tenkrat naprosta vetsina jich nepouzivala nejspis ani deset. Staticke knihovny byly docela bezne a navrhnout sdilene knihovny, aby se chovaly co nejvic jako staticke se muselo zdat jako skvely napad, nekdo na sebe byl mozna i pysny. Problemy s vykonem sdilenych knihoven se neresily, protoze zadne nebyly. Kdo by cekal, ze jednou nejaky KDE team udela sadu knihoven s desetisici dlouhych symbolu? A taky, kdo by cekal, ze za vyznamnou cast problemu u startu mohou sdilene knihovny, kdyz bylo tak v mode to vsechno hazet primo na KDE? Uz jsem tu nekde napsal, ze vyvojari nizkourovnovych veci casto vlastne ani poradne netusi, jak to v praxi ostatni pouzivaji. Pravdu rict se jim ale zase tak moc nedivim, ze se jim nechce prekopat neco tak zakladniho jako je system pouzivani knihoven.

Ale toto nie je len o linkeri, isteho casu som mal prelinkovane KDE, ale aj tak to dlho startovalo.

Dneska je nejvetsi problem pomalost cteni z disku.

Napr. ta ksyscoca, nemoze mat zoznam nacachovanych suborov a potom vyvolat nejaky asynchronny call na stav tych suborov? Nech si to uz jadro nejako usporiada (ci takuto jednoduchu vec kernel nevie?).

Ne. Ksycoca je potreba docela brzo pri startu KDE a nejde ji pouzivat, dokud se nezkontroluje (pokud to neni explicitne vypnuto tim prepinacem). A ne, kernel to vicemene neumi. Dokud si neumi ta data poskladat na disku na jedno misto a precist to naraz, tak to proste bude trvat dlouho. Resp. jako vzdy to zkusime v KDE vyresit planem B :).

Dalsia vec co nechapem, preco musim mat v .desktop a inych suboroch milion kadejakych jazykov, neexistuje na to nejaky nastroj, ktory vyselektuje len tie, ktore ja chcem?

Dokud jich nebude opravdu milion, tak by to v praxi nemelo vadit.

Teraz trochu offtopic - prave som cital v maili to blokove citanie x properties - nemate nejake konkretne cisla? Dost by ma zaujimalo, kolko casu zaberie komunikacia QT/KDE s xserverom pri starte aplikacie.

Nemam na to cisla, jen jsem si dal printf do tech funkci a bylo to malo. Qt/KDE aplikace by obecne mely zpusobovat hodne malo X roundtripu a udajne na vzdalenych X startuji daleko rychleji nez Gtk/GNOME aplikace.

[peter_h]

Rekl bych, ze setrvacnost (tedy krom toho, ze na Windows je vsechno totalne spatne, ELF je prece skvely a tak).

No tak ja by som povedal, ze to je jeden z najhlavnejsich problemov. Plno ludi nadava na windows, ale vacsina vobec netusi, ako funguju. Ked si clovek zacne citat v ich SDK, tak dojde na to, ze kopec veci je tam robenych na co najvacsiu rychlost. To, ze to nefunguje az tak ako autori mysleli, je vec zlej implementacie, ale nechcem tu obhajovat windows. Pravda je, ze teoreticky sa da navrhnut super system, kde je vsetko abstrahovane, ale asi by ten vykon za vela nestal (volat na kazdu vec funkciu..). Preto sa mi paci java, lebo tam sa to zoptimalizuje viacmenej za behu .
Ten argument dole, ze i386 ma maly adresny priestor - to vobec nevadi, nejde o to nahrat vsetky kniznice naraz. Treba sa len dohodnut, ktore hlavne kniznice ktory priestor dostanu a ostatne nemusia by prelinkovane. Ja napr. zas nechapem, preco sa nemoze prelinkovat oproti non-pic, ved ho capnem kam patri a tu adresu necham vyhradenu.

Dneska je nejvetsi problem pomalost cteni z disku.

Ale ved tie kniznice sa strankuju postupne, ako sa vykonava kod, nenahravaju sa vsetky naraz a cele. Niekde v ld je taky prepinac, co oprofiluje kod tak, aby boli funkcie ktore sa casto volaju "pri sebe", teda najlepsie na jednej stranke, zabera to potom menej pamate a malo by sa to aj rychlejsie nacitat. Skusal to niekto?
Nechcem sa tu navazat do KDE, ja ho pouzivam ako svoj DS, ale nie je tak trochu problem aj v tom, ze je trosku "naboptnane"?

A ne, kernel to vicemene neumi. Dokud si neumi ta data poskladat na disku na jedno misto a precist to naraz, tak to proste bude trvat dlouho.

Tak si urobte FUSE ovladac ktory tie data na to jedno miesto da a hotovo .
Ja som si vzdy myslel, ze toto robi IO scheduler, ze preusporaduva poziadavky tak, aby sa data citali z disku co najefektivnejsie.

[MJ]

Treba sa len dohodnut, ktore hlavne kniznice ktory priestor dostanu a ostatne nemusia by prelinkovane.

Ale přesně tohle linuxový prelink dělá, ne?

Ja som si vzdy myslel, ze toto robi IO scheduler, ze preusporaduva poziadavky tak, aby sa data citali z disku co najefektivnejsie.

To samozřejmě scheduler dělá, ale jen tehdy, když o těch všech požadavcích ví, tedy když vzniknou najednou. Pokud nějaký program čte soubory postupně, těžko s tím kernel něco zmůže

[peter_h]

Ale přesně tohle linuxový prelink dělá, ne?

Tak kde je problem s adresnym priestorom? Mam taky dojem, ze to robi len s nejakym prepinacom, ale ide o to, ze to ide nastavit.

To samozřejmě scheduler dělá, ale jen tehdy, když o těch všech požadavcích ví, tedy když vzniknou najednou. Pokud nějaký program čte soubory postupně, těžko s tím kernel něco zmůže

Tak to si musim pozret ako ta cache vlastne funguje, lebo takto sa mi zda akoby nahradzala zbytocne diskovu cache.

[peter_h]

Aha, pardon, nejako som prehliadol ten post o tom, ze ksyscoca je subor, ale aj tak sa mi straca jeho vyznam, ked sa musia skontrolovat vsetky subory (ja som si to btw. tusim vypinal )

[Luboš Luňák]

Jde precist jednim blokovym ctenim treba 50MB za sekundu, ale jde udelat jen 100 cteni za sekundu -> cist jeden velky ksycoca soubor je lepsi nez cist stovky malych .desktop souboru.

[Luboš Luňák]

Jenze prelink nefunguje s dlopen() a dokud se neudela nejaky trik jako dela -Bdirect, tak nikdy fungovat nebude. Navic ma prelink jeste par dalsich drobnych problemu, jako treba ze soubory se tak trochu zvetsuji, takze to zpusobuje fragmentaci na disku.

[peter_h]

Aku fragmentaciu? Ved linuxove fs sa nefragmentuju . Ale vazne, malo by to fungovat tak, ze to uz je prelinkovane distributorom, pri gentoo a podobnych distribuciach je hovorit o fragmentacii koli prelinku "mimo misu".
To je taky problem aby dlopen nahral tu kniznicu na to miesto, ktore jej bolo urcene? Ako to, ze pri DLL to funguje. Typicky problem OS - nikto sa na nicom neviem s nikym dohodnut.

[Luboš Luňák]

http://people.redhat.com/jakub/prelink.pdf - myslim, ze nema smysl tohle tady dal rozebirat.

[MJ]

A preco to vlastne nemoze fungovat na 100% ako pri DLLkach? Tie su vlastne prelinkovane vsetky.

Důvod je jednoduchý: i386 má tak maličký adresní prostor, že se do něj nemají všechny nainstalované knihovny šanci vejít.

O něco vzdáleně podobného se pokouší zde již zmiňované prelinkování: podívá se, které knihovny se používají současně a zkusí je předpřipravit pro umístění na takových adresách, aby se pokud možno vešly a navzájem nepřekrývaly. Když za běhu nastane jakákoliv kolize, dořeší se to stejně jako normálně relokacemi.

[brozkeff]

Nechápu všechno to špekulování nad tím, jak obcházet tohle a tamto při takovém a makovém nestandartním přístupu :-P Stačí používat KDE jako takové a je po problémech! Na všech dnešních strojích je po počátečním načtení svižné (rozhodně svižnější než Gnome, IMHO), a tím "dnešních" myslím i takové cca 3-4 roky staré s 1GHz procesorem a min. 256MB RAM. S 512MB RAM je už vše úplně optimální. A to dneska, když vidím všechny ty hulánovská doporučení, bych pomalu čekal, že nikdo nebude mít míň jak 1GB RAM :))

[Non_E]

Ahoj, já jsem sice zastánce KDE, ale viděl jsem na fakultě FC5 s gnome a co se týče rychlosti, nemůže se s nimi můj desktop srovnávat (co se týče featur taky ne ). Veškeré aplikace včetně firefoxu startovaly okamžitě. Jen jsem kliknul a bylo to. Neměl jsem čas studovat, jestli jsou nejčastější programy načteny do ram nebo jak to přesně udělali. Školní stroje byly kolem 3800+ s 1GB ram.

Na druhou stranu chápu "ty ostatní", kteří by rádi jen jednu nebo dvě kde aplikace. Načtení k3b pak už nemusí být mých (pouze/?) šest sekund.

[brozkeff]

Hm, já s Athlonem XP 2600+, 512MB RAM a ATA diskem s 2MB cache teda mám zkušenosti s KDE mnohem pozitivnější než s Gnome. Gnome mě většinou když jsem ho zkoušel někde leakovalo (Firefox zvláště;) a kromě jiného se mě nemožnost nastavit si první poslední iritovala :) KDE je prostě pro mě optimální - zvykl jsem si, a mám rád KDE aplikace... i když namísto takového Kopete, co mě donedávna také leakovalo a po pár hodinách padalo, používám konzervativně Gaim (už jenom kvůli tomu, že mě jede i ve Win... tedy především ve Win) No flame, pleeease :)

[Non_E]

Ale že to běží rychleji ještě nevypovídá jak moc rychle to běží. Doba startu není jedinou veličinou, která by vypovídala o rychlosti aplikace, ale docela špatně se měří.

Mám podobnou sestavu (Athlon XP@1925MHz, 512MB PC3200 ram a dva disky po 8 MB cache) a výkon se snažím získat "kde se dá".

[Luboš Luňák]

"Pouze" 6 sekund na k3b? To asi nebude jako ty 3800+ masinky - na necem takovem musi byt okamzite skoro vsechno, nejen Firefox a GNOME.

[Non_E]

Souhlas, i OpenOffice naběhl napoprvé za pár sekund (málem jsem si ani neprohlédl splashscreen).

K3b používám jednou za uherský rok, takže 6 sekund k několika minutám skládání kolekce a vypalování psychicky snesu. Přímé srovnání nemám, práva roota k nstalaci sw nám na fakultě nedali (i když jsem nezkoušel všechna bezpečná hesla jako nbusr123 resp. PrFMU123 a na moje hrátky s livecd nebo single modem by se asi správce nedíval moc nadšeně) a proto můžu srovnat jen toho firefoxe. Ten se mi načítá 12s včetně úvodní stránky na abclinuxu. Načítání stránky mi zabere odhadem 3-5s (přeci jen nejsem ani na páteřní síti). Od oka je u mě načtení ff 10-15x pomalejší.

Naštěstí je po startu KDE přednačtena instance konqueroru a jeho "start" je pak se zmíněným foxem ve škole srovnatelný.