GIO je pomalej šmejd

25.6.2009 20:22 | Přečteno: 1280× | Jiné

Ano, je to tak. GIO je pomalej šmejd. Dneska jsem zjistil, že v SVN repozitáři Thunaru je branch migration-to-gio. Tak jsem to zkusil zkompilovat. Zkompilovalo se a zkusil jsem. Otevřu /usr/lib64 a několik sekund to šrotovalo na disku než to ukázalo obsah adresáře. Zkusím ještě 3x za sebou, když už je adresář v cache - to je o něco rychlejší, ale stále nic moc. Tak a teď pustím starý Thunar fungující na ThunarVFS. Otevřu /usr/lib64 a světe div se - je to minimálně 3x rychlejší než GIO varianta. Zkusím ještě 3x a stále stejně rychlé. Ještě znovu zkusím Thunar/GIO a potvrdím si, že je to pamalý.

Závěr: GIO = pomalej šmejd. Sice má použití GIO své výhody (jako mountpointy viditelné ve všech GTK aplikacích), ale oproti tomu 3x nižší rychlost je nechutnost. A teď si vemte, že kdyby ThunarVFS nečetl každý soubor v adresáři a zjišťoval typ souboru efektivnějším způsobem (tj. podle přípony), ukázal by se adresář okamžitě, jak se tomu děje např. v Tux Commanderu. A u souborů bez přípon by mohl testovat execute bit a pokuď tam není, tak kouknout dovnitř a určit typ na základě obsahu. Jenže to by každej měl tři prdele keců, že určovat typ podle přípony je špatné. Přitom je to několikanásobně rychlejší, než přečíst jánevimkolik bajtů ze souboru a porovnat s mime databází.

       

Komentáře

[thingie]

Není nad vědecký přístup.

€ time gvfs-ls /usr/lib/ >/dev/null

real    0m0.141s
user    0m0.088s
sys     0m0.038s



€ time ls /usr/lib/ >/dev/null

real    0m0.029s
user    0m0.008s
sys     0m0.014s
 

(Ano, je to sice zhruba pětkrát pomalejší, ale je to dost rychlé na to, aby to bylo dokonale jedno.)

 

[pozortucnak]

Jé, nazdar Jardo, dávám dobré jako posledně...

[Jardík]

Šmíde mizernej! To ti vrátim

[R]

Konecne nieco ako KIO, akurat riesenie je typicke pre GTK - pomale ako svina...

[Jardík]

[robotics]

Jdu otestovat tuxcommander. Naposled co sem zkoušel commander Gentoo tak mi přišel hodně dobrej, jen mě odradil hnusný vzhled.

[Salamek]

jdi do řitě s určováním dle přípony to je widlojidní jak svina , navíc jsem si odvykl psát přípony k většině souborů

[Ladicek]

Argumentovat, že je to widloidní, může akorát vidlák. Přípona souboru je docela užitečná konvence, a je pořád spousta situací, kdy se na ni dá spolehnout. Dělá snad někdo zdrojáky v Céčku bez přípony nebo třeba s příponou pas?

[thingie]

Trochu problém asi je, že ta konvence jako taková neexistuje, je to spíše jen roztroušená sada různých zvyků pojmenování. GCC si třeba může dovolit dělat nějaké lehké předpoklady na základě jména souboru, ale pro celosystémový obecný nástroj to asi není.

[Ladicek]

Proto níže mluvím o atributu user.mime_type a říkám, že libmagic je spolehlivější. I když ani ty MIME typy nejsou samospasitelné.

[thingie]

Rozšířené atributy jsou zabité asi ještě víc než přípony, tím se to myslím moc nevyhraje. Pokud se vůbec nějak dá. Jenom se mi zdá, že ten Thunar neřeší typ souboru nějakým asynchronním způsobem. Podívat se do adresáře a udělat stat nad tím co tam je, to trvá i na hodně velkých adresářích jen chviličku. Ikonky si může vymalovávat potom. To je trochu hloupé.

[Salamek]

no u c/c++/php přípony používám .c,cpp, .h,.php ale prostě textáky nebo sh , bin přípony nedávám

[Ladicek]

Zkoušel jsi, jestli to umí používat atribut user.mime_type? Používání libmagic pro určování typu souboru je z výkonnostního hlediska absolutní multikill, ale zase to je spolehlivější než podle přípony.

[Grunt]

určovat typ podle přípony je špatné.

A není?

BTW: Zkus gprof.