Vlákno názorů k článku Akta X: EXI čili binární XML od Palo - Precital som si vsetky prispevky a az na...
-
Palo (neregistrovaný)Precital som si vsetky prispevky a az na dva mam dojem ze tomu nikto nerozumie. Robil niekto z vas co tu pisete XML parser (a validator voci XSD vratane namespace)? Uvedomujete si ze binarne XML sluzi hlavne na to aby sa tento XML to Memory alebo XML to internal structure nemusel robit? A az ako dalsia vlastnost je ze je to mensie. O velkost tu primarne vobec nejde.
Cez kolko vrstiev obvykle prechadza XML od povedzme klienta az po databazu? Rozumiete niektorym principom Enterprise message bus?
Potom nam sem nieco mudre napiste. Iniciativa je fajn. Treba to dotiahnut do praktickych implementacii. V kazdom pripade to velmi zrychli komunikaciu.
Trochu som sa rozohnil ale ludia co trepu do veci ktorym nerozumeju ma hrozne vytacaju a este sa tvaria ze oni su prave ti mudry. Lebo ak si niekto mysli ze ludia co pobehuju okolo W3C nevedie o Huffmanovej transformacii tak mate velmi naivne predstavy o fungovani sveta hraniciace s navstevou psychologa. -
Programátor (neregistrovaný)Máte pravdu, mě zase rozčilujou přechytralí fanoušci XML. Takové lidi je správné popíchnout.
Doufám že jste ten praser (u XML tomu odmítám říkat parser) nepsal v projektu nebo v grantu placeném z mých daní. A když už jsme u těch parserů pro stromové datové struktury, znáte Lisp? -
Jan Bauer (neregistrovaný)Clanek se mi nelibi, je znacne zkresleny a vzdy rikam, ze neni nad original.
Binary XML je skvele, uz se nemohu dockat az bude vsude podporovano. Samozrejme dojde opet ke snizeni vykonu, ale procesory jsou levnejsi, nez rychlejsi pripojeni k internetu a bude velmi pekne, az napriklad takovy xmlHttpRequest() probehne o 50% rychleji diky prenosu zkomprimovanych dat.
Nadruhou stranu muze byt problem, az zacnou firmy pozmenovat ona binarni data tak, aby je vetsina lidi nemohla pouzit - na obsfukaci jsou takovi ti praseci programatori primo spicky. Obcas se nevyznaji ani ve svem vlastnim kodu, natoz my po nich. Ukazkovy priklad mohou byt jmena a hodnoty formularovych prvku na strankach T-mobile. -
anonymníProblém je, že W3C se učí základy programování. To co my už máme za sebou, W3C teprve bude studovat později. Zatím asi kdosi objevil Huffmana a bitová pole - a tak to nadšení musí někde ventilovat. Naše smůla, že zároveň určují standardy. A to teprve bude radosti, až třeba W3C komise objeví Quicksort!!! To bude určitě nějaký další standard - XML formát optimalizovaný pro rychlé třídění dat.
-
BLEK. (neregistrovaný)Doporučil bych obyčejné 32-bitové číslo, zarovnané na hranici 4 bytů. (předpokládám, že XML komise ještě nedosahují takové výkonnosti, aby standartizovali DTD s víc jak 2^32 elementů :-)
Huffmanův kód není špatná věc, jen by člověk u každého algoritmu měl zvážit, zda v daném případě jsou výhody přinesené algoritmem větší než nevýhody. Vy si taky do poznámkového bloku nepíšete poznámky Huffmanovým kódem --- sice byste ušetřil nějaký papír a tuhu, ale ztratíte spoustu času, když to budete kódovat a pak po sobě luštit :) -
BLEK. (neregistrovaný)Huffmanův kód je efektivnější na zmenšení množeství dat, ale množství dat zde není úzké hrdlo --- úzké hrdlo je zátěž CPU. (gigabitový ethernet zaplácaný XML, které se rovnou stíhá parsovat? diskové pole čtoucí XML rovnou do parseru rychlostí 300 megabytů za sekundu? --- to si lze asi těžko představit)
Psal jsem HTML parser (nikoli XML) a funkce, co spotřebovala nejvíc času --- asi 30% --- dělala hledání atributů u tagů. Takže, kdybych chtěl navrhnout binární rychle-parsovatelné HTML, tak bych udělal:
- ukazatel na další atribut
- hash jména atributu (pokud to není atribut, co chceme, tak rovnou skočíme na další bez porovnávání jména)
- délka jména (memcmp je rychlejší než strcmp)
- jméno
- hodnota atributu, ukončená nulou (aby se pointer na ni dal rovnou předávat funkcím v C)
(v rozpoznávání tagů mi profiler kupodivu ani nezobrazoval moc stráveného času, důležité byly atributy)
Jak by tomu měl pomoct Huffmanův kód, si nedokážu představit. -
Palo (neregistrovaný)Aka zataz CPU ked uz to bude rovno v memory like forme? Ale RAM to ustiha vzdy. Najpomalsia cast vypoctoveho systemu je stale disk. Siet a pamat je OK. Vacsina XML sa uklada az niekde na konci spracovania.
To ze ty si to nevies predstavit este neznamena ze je to zle. Podla testov ktore su spomenute v clanku prave tato metoda bola najrychlejsia. Nerozumies faktom? -
BLEK. (neregistrovaný)A to chtějí používat tu kompresi po bitech už v paměťové formě?
Pomalost disku? Hardwarové pole zvládne 300 megabytů, ale nedokážu si představit program, který data touhle rychlostí bude nějak zpracovávat (kromě triviálních utilit typu "cp" --- ale i ty už jsou při těchhle rychlostech na hranici svých možností a konzmují skoro všechen procesorový čas).
Pomalost disku tkví hlavně v dlouhé době seeku, ta nejvíc zpomaluje aplikace. Pokud máme např. obyčejný disk do PC, tak má přenosovou rychlost 50MB/s a dobu seeku 8ms. Ale vmstat nám ukazuje pod zátěží přenosovou rychlost třeba pouze 10MB/s. To znamená, že ten disk 80% času seekuje a pouze 20% času čte. Pokud nějakou kompresí zmenšíme množství přenesených dat dvakrát, tak bude doba seeku pořád stejná, takže jsme si ve výsledku pomohli jen o 10% (a procesor jsme tou kompresí zatížili o několik stovek procent víc).
Ad ty benchmarky --- ty spíš ukazují programátorské schopnosti jednotlivých týmů, než kvalitu formátu a algoritmů. Kdyby někdo dal specifikace formátů nezávislým týmům a nechal je to reimplementovat, tak dostane benchmarky úplně jiné. -
xyzzy (neregistrovaný)Schvalne si to zkuste. BLEK ma podle me naprostou pravdu.
Na rychlosti nacitani do pameti se o 50% kratsi delka (ktere se tak nejvys dosahne pres Huffmanovu kodovani) tolik neprojevi. Ale uspora pri parsovani by mohla dosahnout i stovek procent, pokud by bylo mozne okamzite (porovnanim) poznat tag/atribut a skocit na dalsi.
Dalsi faktor je kodovani. Aby si mohly aplikace predavat data, museji je zakodovat do XML. Pokud budou pouzivat vicemene primo in-memory format (ktery jen poskladaji do nejakeho bufferu), tento krok odpadne.
Ted nad tim tak premyslim, a kdyby nejaka aplikace chtela ve velkem binarnim XML jen neco zmenit, a pak ho zase ulozit, tak by Huffmanovo kodovani bylo velmi nevyhodne. Zbytek od te zmeny by se totiz musel bitove posunout (prinejmensim). V BLEKove formatu by se to delat nemuselo. -
Palo (neregistrovaný)O com to tu pisete? Ved predsa nikto netvrdi ze v pamati to bude tiez v Huffmanovom kodovanim. To je serialova forma na prenos medzi systemami. A prave ta Huffmanova forma bola v testoch najrychlejsia.
Ja tu nemiemim polemizovat o Blackovom formate. Ten ma vobec nezaujima. Ak si myslite ze to zvladnete lepsie, W3C Vas iste rada vypocuje.
Ten format musi byt iba memory like aby bol multiplatformovy, multijazycny. Citali ste clanok, pripadne thread?
